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ABSTRACT 


This  thesis  presents  a  software  implementation  in  JANUS/ADA  of  the  Radar 
Scheduler  process  based  on  previous  thesis  work  developed  for  the  NPS  AEGIS 
Modeling  Project.  The  project  is  an  emulation  of  the  AEGIS  AX/SPY- 1 A  Radar 
Control  Program  for  a  multi-microprocessor  system.  This  thesis  is  a  first  effort  in 
implementing  the  NPS  AEGIS  project  model  in  JANUS/ADA.  Included  are  the  results 
of  the  preliminary*  reai-time  testing  and  logical  tests  of  the  Radar  Scheduler  module. 
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THESIS  DISCLAIMER 


.  1 


The  reader  is  cautioned  that  computer  programs  developed  in  this  research  may  not 
have  been  exercised  for  all  cases  of  interest.  While  every  effort  has  been  made,  within 
the  time  available,  to  ensure  that  the  programs  are  free  of  computational  and  logic 
errors,  they  can  not  be  considered  validated.  Any  application  of  these  without 
additional  verification  is  at  the  risk  of  the  user. 

Some  terms  used  in  this  thesis  are  registered  trademarks  of  commercial  products. 
Rather  than  attempt  to  cite  each  occurrence  of  a  trademark,  all  trademarks  appearing 
in  this  thesis  are  listed  below'  the  firm  holding  the  trademark: 

1.  U.  S.  Government  (AJPO) 

a.  ADA  Programming  Language 

2.  RR  Software.  Inc. 

a.  JANUS/ADA  Programming  Language 

3.  Digital  Research.  Box  579.  Pacific  Grove.  California 
a.  PL/ 1-80  Programming  Language 

4.  Intel  Corporation,  Santa  Clara,  California 
a.  iSBC  86/12A  Single  Board  Computer 

5.  Zenith  Data  Systems  Corporation 
a.  Z-100  Series  Computer 
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I.  INTRODUCTION 


The  AEGIS  Combat  System  (ACS)  is  an  automated,  rapid  reaction  shipboard 
combat  system.  As  an  automated  combat  system,  it  is  designed  to  control  shipboard 
sensors,  manage  electronic  data  processing,  and  assist  in  the  making  of  time  critical 
combat  decisions  while  simultaneously  engaging  air,  surface,  and  subsurface  threats. 
Additionally  an  AEGIS  platform  posesses  the  capacity  for  defending  its  accompanying 
forces  against  the  same  threats.  To  meet  this  demanding  environment  the  ACS  relies 
on  a  specially  designed  computer  system  to  assist  in  every  phase  of  combat 
engagement. 

At  present  the  computer  system  is  composed  of  three  banks  of  four  processors 
and  up  to  three  uni-processor  AN/UYK-7  computer  systems,  totalling  fifteen  32-bit 
processors.  In  addition,  there  are  six  or  more  AN/UYK-20  16-bit  minicomputers  sn 
the  system  making  the  AEGIS  system  the  largest  network  of  computers  dedicated  to  a 
combat  system.  The  faculty  and  olTicer  students  at  the  Naval  Postgraduate  School  have 
been  interested  in  ways  to  reduce  the  costs  of  the  ACS  without  compromising  its 
capability.  As  a  resuit  the  Naval  Postgraduate  School  developed  the  AEGIS  Modeling 
Group  to  study  the  problem.  The  group's  major  goal  and  approach  to  the  problem  is 
to  model  the  AEGIS  Combat  System's  computer  suite  using  multi-microprocessor 
technology  and  the  latest  software  engineering  principles. 

The  feasibility  of  a  multi-microprocessor  approach  was  first  addressed  by 
Gayler's  thesis  [Ref.  1:  p.  15].  Gayler  explains  that  state  of  the  art  advances  in 
microelectronics  should  be  used  as  an  alternate  method  of  processor  implementation  in 
future  AEGIS  platforms.  In  order  to  realize  the  benefits  of  large  scale  integration 
(such  as  reduced  size,  weight,  cost,  and  an  increased  reliability)  a  distributed  multi¬ 
microprocessor  architecture  was  proposed.  Further  studies  into  the  hardware 
implementation  were  carried  out  in  thesis  work  by  Dilmore  [Ref.  2:  pp.  7-70]  which 
describe  hardware  implementation  for  the  NPS  model.  After  the  hardware  decisions 
were  made  for  the  model,  Riche  and  Williams  [Ref.  3:  pp.  11-232]  laid  out  the  design 
for  the  software  foundation  for  the  AN/SPY-1A  radar  control. 

The  NPS  design  of  the  software  places  a  major  emphasis  on  concurrent  process 
management,  both  asynchronous  and  periodic.  A  Multi-Computer  Real  Time 
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Executive  (MCORTEX)  was  developed  in  a  sequence  of  six  thesis  projects  to  permit 
parallel  processing  in  each  computer  in  the  multiprocessor  system.  At  present,  thesis 
work  is  being  done  to  provide  concurrent  process  management  by  creating  an  ADA 
language  interface  to  the  MCORTEX  system.  MCORTEX  can  then  be  used  to 
coordinate  the  asynchronous  processes  of  the  ACS's  model  in  a  multi-microprocessor 
environment.  The  main  objective  of  this  thesis  is  to  implement  the  Radar  Scheduler 
process  using  the  JANUS/ADA  programming  language.  This  in  turn  will  provide  a 
major  portion  of  the  overall  model  and  the  opportunity  to  study  the  feasibility  of  real¬ 
time  programming  in  ADA. 

Chapter  II  of  this  thesis  presents  the  software  documentation  principles  for  the 
NPS  model  of  the  ACS.  This  includes  a  discussion  of  the  Janus  Ada  programming 
language  and  an  explanation  of  the  program  documentation  scheme  used  by  the  NPS 
AEGIS  Modeling  Group.  Chapter  III  describes  the  NTS  model  of  the  Radar  Control 
System.  A  functional  description  is  given  for  of  each  the  Radar  Control  Group 
modules  to  be  modeled.  A  more  detailed  description  of  the  Radar  Scheduler  is  provided 
in  Chapter  IV.  Chapter  IV  presents  the  Radar  Scheduler  design  and  necessary 
documentation  for  the  Radar  Scheduler  source  code.  This  is  the  major  section  of  this 
thesis  which  emphasizes  the  functional  requirements,  data  structure  specifications,  and 
an  explanation  of  the  algorithms  implemented  by  the  Radar  Scheduler  program. 
Chapter  V  provides  information  on  testing  the  algorithms  implemented.  This  includes  a 
discussion  on  the  module  testing  philosophy  for  time  critical  programs  and  the  strategy 
used  in  testing  the  Radar  Scheduler  modules.  Chapter  VI  presents  the  conclusions  and 
recommendations  for  further  research. 


10 


II.  SOFTWARE  DOCUMENTATION 


A.  SOFTWARE  ENGINEERING  PHILOSOPHY 

The  primary  goal  of  software  engineering  is  to  improve  the  quality  of  software 
products  while  increasing  the  productivity  of  software  engineers.  This  goal  applies  as 
well  to  the  AEGIS  Modeling  Group.  Due  to  the  continuing  turn  over  and  time 
constraints  of  research  students,  it  is  essential  that  this  project  be  based  on  sound 
software  engineering  principles.  In  view  of  this  the  AEGIS  Modeling  Group  has 
adopted  the  following  philosophy.  First,  both  the  design  and  the  source  code  must  be 
clear,  easy  to  understand,  and  modifiable.  Second,  the  model  must  be  constructed 
within  the  constraints  of  the  AEGIS  program  specifications. 

The  first  goai  mentioned  is  achieved  through  a  top  down  modular  design,  using 
structured  programming.  Moreover,  the  documentation  must  also  emphasize  ins 
hierarchical  structure  with  the  upper-most  level  of  documentation  presenting  "he  least 
detailed  view  and  successive  levels  becoming  more  and  more  detailed.  This  way  the 
reader  is  not  overwhelmed  by  details  and  thus  is  more  aoie  to  grasp  the  structure  of  the 
program. 

The  second  goal  relating  to  program  specifications  is  very  important.  Unless  the 
design  is  based  on  a  firm  knowledge  of  the  program  specification,  the  modeling  effort  is 
in  vain.  Each  module's  documentation  will  include  a  description  of  its  purpose.  All 
modules  are  constructed  so  that  they  obey  the  functional  specifications  of  the  AEGIS 
AN/SPY- 1A  Radar  Controller  software. 

B.  THE  ADA  PROGRAMMING  LANGUAGE 

The  ADA  programming  language  was  designed  in  accordance  with  the 
requirements  defined  by  the  United  States  Department  of  Defense.  In  general,  these 
requirements  call  for  a  language  with  considerable  expressive  power  over  a  wide 
application  domain  [Ref.  4:  p.  1-1].  Of  particular  interest  in  our  application  is  the 
languages  ability  to  cover  real-time  programming.  To  support  real-time  programming, 
ADA  provides  facilities  to  model  parallel  tasks  and  to  handle  exceptions. 
Unfortunately,  the  ADA  language  implementations  do  not  provide  runtime 
environments  for  multi-single-board  computer  based  systems.  In  order  to  use  the 
multiprocessor  environment,  the  M CORTEX  operating  system  is  used  to  permit 
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parallel  processing  in  the  ADA  language.  In  particular,  use  is  made  of  the 
JANUS/ADA  language,  which  differs  from  the  fully  validated  ADA  primarily  because 
tasking  and  generics  have  not  yet  been  implemented.  Since  the  MCORTEX  operating 
system  is  used  for  parallel  processing,  there  is  no  need  for  the  tasking  features  of  the 
ADA  language,  and  therefore  JANUS/ADA  is  suitable  as  the  programming  language 
to  implement  the  present  version  of  the  AEGIS  model. 

In  the  JANUS/ADA  programming  language  modules  are  composed  of  packages 
that  can  be  separately  compiled.  The  package  usually  contains  a  specification  and  a 
body.  Each  of  these  parts  reside  in  separate  files  for  compiiation  purposes.  Files 
containing  the  modules  specification  have  the  file  type  "LIB".  Files  containing  the 
package  body  have  been  given  the  default  JANUS,  ADA  file  type  "PKG". 

ADA's  enumeration  types  allow  the  user  to  add  clarity  to  the  code  and  program 
at  a  much  higher  levei  of  abstraction.  The  cianty  is  achieved  by  creating  data 
structures  that  can  be  easily  read  rather  than  having  to  decipher  their  purpose  in  the 
code. 

C.  PROGRAM  DOCUMENTATION  REQUIREMENTS 

Documentation  of  the  Radar  Scheduler  Model  program  in  this  thesis  is  in 
keeping  with  the  PL,  1-80  version  which  was  modeled  after  the  Software  Requirements 

for  the  A7-E  Aircraft  document.  The  requirements  call  for  documenting  design 
decisions  that  will  impact  the  future  development  of  the  program,  what  the  functional 
requirements  of  the  program  are,  what  the  interface  data  structures  are  composed  of, 
how  the  program's  internal  data  structures  wrere  fashioned,  and  the  modular 
decomposition  of  the  program.  [Ref.  5:  p.  23] 

All  the  design  decisions  which  were  made  for  the  Radar  Scheduler  Model  can  be 
found  in  Chapter  4  which  serves  as  a  module  design  document.  Each  Radar  Scheduler 
module's  design  documentation  contains  the  following: 

1.  A  functional  abstract  description  of  the  module, 

2.  Common  memory  interface, 

a.  Data  structures  consumed, 

b.  Data  structures  produced, 

3.  Internal  process  data  structures, 

a.  Data  structures  consumed, 

b.  Data  structures  produced, 


4.  Local  module  data  structures, 

5.  A  description  of  the  module  in  an  algorithmic  language. 

Design  decisions  made  for  the  purpose  of  testing  the  Radar  Scheduler  are  documented 
in  Chapter  V. 


—  OWNER:  AEGIS  Modeling  Group 

—  DATE  OF  LAST  UPDATE:  7  Dec  86 

—  MODULE  TYPE:  Skeleton  Sample  {Vers  1.0} 

—  PL  RPOSE:  Depict  format  for  module  source  code 

—  NAME:  Sample  ...  Fig2.pkg 

—  This  sampie  module  source  code  skeleton  represents 

—  the  format  to  be  used  in  documenting  modules. 

WITH  global, tables;  —  declare  global  data  structures 

--  and  common  memorv 

PACKAGE  BODY  fig2  IS 
USE  global. tables; 

TYPE  localvar  IS  INTEGER;  —  declare  anv  local 
var:  localvar;  *-  module  variables 

PROCEDURE  sample) parameter:  IN  INTEGER)  IS 
procvar:  INThGER:  -  declare  procedure  variables 

BEGIN 

—  code  lor  the  procedure 
END  sample: 

BEGIN 

—  If  desired  local  or  global  variables 

—  can  be  initialized  here. 

—  If  this  module  was  not  designed  for  the 

—  procedure  "sample"  then  the  code  for  the 

—  main  program  '  sample"  would  go  here. 

END  fig2; 


Figure  2.1  Source  Code  Documentation. 

Code  documentation  must  maintain  a  balance  between  verbosity  and  scarcity  of 
comments.  The  prime  objective  is  to  increase  readability  and  ease  the  task  of 
maintenance.  An  example  of  the  format  for  source  code  documentation  in  this  thesis  is 
given  in  Figure  2.1  .  The  source  code  documentation  used  in  this  thesis  can  be 
generally  broken  into  three  parts,  a  module  header,  a  module  description,  and  short 
comments  for  code  explanations  that  may  not  be  apparent  to  the  reader. 

The  purpose  of  the  module  header  is  to  introduce  the  module  to  the  reader.  The 
header's  template  format  helps  to  insure  that  vital  information  is  not  overlooked,  while 
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adding  to  the  structured  approach  of  the  documentation.  Each  module  header  provides 
the  reader  with  the  following  information: 

1.  Who  the  owner  of  the  module  is. 

2.  The  date  that  the  module  was  last  altered. 

3.  The  type  of  module  and  the  current  version  number. 

4.  The  purpose  for  which  the  module  was  written. 

5.  The  English  language  equivalent  name  of  the  module  and  the  file  name  it  is 
stored  under. 

Following  the  module  header  is  the  module  description.  The  module  description 
is  used  to  explain  the  general  functional  logic  which  controls  the  execution  of  the 
algorithm  implemented  by  the  module.  Included  in  the  module  description  are  the 
input  and  output  parameters  used  by  the  module. 

The  last  type  of  documentation,  short  in  code  comments,  are  used  to  introduce 
the  major  functions  within  the  module.  The  comments  will  describe  what  the  function 
has  been  designed  to  do. 

D.  variable  naming  CONVENTIONS 

A  common  pitfail  of  the  applications  programmer  is  "excessive  contraction"  of 
variable  names.  In  keeping  with  the  desire  to  maximize  readability,  the  convention  for 
naming  variables  is  based  on  two  principles.  First,  that  the  variable  name  be  long 
enough  to  be  unique  to  the  language  and  the  reader,  and  second,  that  the  name  reflect 
the  variables  purpose.  However,  if  the  lengths  of  the  variable  names  are  too  long,  it 
becomes  difficult  to  organize  the  source  code  to  fit  on  the  standard  8.5  inch  by  1 1  inch 
page.  Consequently  the  programmer  must  consider  the  fact  that  he  will  not  be  the  only 
one  to  read  his  code  and  decide  accordingly. 

In  the  case  of  this  thesis  variable  naming  was  based  on  the  PL/I-SO  version 
names.  The  reason  for  this  decision  was  to  avoid  confusion  on  the  part  of  future 
researchers.  This  was  necessary  since  the  majority  of  the  variables  are  defined  by 
common  memory  interface  data  structures  that  were  designed  in  the  early  stages  of  the 
Radar  Control  Group  modeling  process.  Since  these  data  structures  act  as  interfaces  to 
the  other  major  processes,  adding,  changing,  or  deleting  variables  in  these  data 
structures  was  not  a  decision  that  should  be  made  from  the  Radar  Scheduler  processes 
design  level. 
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E.  FILE  NAMING  CONVENTIONS 


A  File  naming  convention  has  been  established  in  order  to  keep  track  of  the  large 
number  of  files  that  make  up  the  the  Radar  Controller  model.  This  convention  has 
been  preserved  by  this  thesis  in  order  to  maintain  consistance  with  the  previous 
versions.  The  JANUS/ADA  modules  in  this  thesis  have  been  named  after  their  PL/I-80 
predecessors  so  that  their  names  will  serve  as  a  cross-referencing  tool  to  facilitate 
future  research. 


TABLE  1 

NPS  AEGIS  MODULE  NAMING  CONVENTION 


MODULE  NAME 

CODE 

FILE  NAME 

CONTROL  GROUP 

Radar  Scheduler 

R 

RRCM 

Search  Management 

SRCM 

Track  Management 

m 

TRCM 

Radar  Return  (innut) 

f 

I  RCM 

Radar  Cutout 

0 

ORCM 

Channel  I/O  Control 

H 

HRCM 

SUPPORT  GROUP 

Switch  Action  and  Dicoiay 

A 

ARCM 

CGD  User  Services 

n 

CRCM 

Beam  Stabilization 

3 

BRCM 

Detection  Processing 

D 

DRCM 

ECM/Clutter  Processing 

E 

ERCM 

Frequency  Management 

F 

FRCM 

Track  Association 

K 

KRCM 

Load  Evaluation 

L 

LRCM 

Missile  Communications 

M 

MRCM 

WCS  User  Services 

W 

WRCM 

Cross-Gating 

X 

XRCM 

The  scheme  for  naming  the  files  is  presented  in  Table  1  .  Each  of  the  major 
processes  is  assigned  a  unique  one  letter  process  identifier  code.  This  code  followed  by 
the  letters  "RCM",  make  up  the  file  name  which  stands  for  "Radar  Control  Module". 
Each  of  these  major  processes  is  composed  of  several  subordinate  modules.  The  file 
names  of  the  subordinate  modules  correspond  to  the  initials  of  their  parent  process 
followed  by  a  module  number.  For  example,  the  first  module  within  the  Switch  Action 
and  Display  process  would  have  the  file  name  "SADM1"  which  stands  for  Switch 
Action  and  Display  Module  1. 
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If  the  modules  are  further  subdivided  into  submodules  and  subroutines  then  they 
are  uniquely  identified  through  file  name  typing.  That  is,  the  filename  takes  on  the 
parent  process  initials  and  module  number  followed  by  a  submodule  letter  (A-Z).  For 
instance,  the  Track  File  Initialization  module,  DPMI,  which  is  part  of  the  Detection 
Processing  Module,  has  a  subroutine  which  is  used  to  place  a  node  at  the  end  of  a 
linked  list.  Since  this  subroutine  is  part  of  DPMI,  it  has  the  file  name  DPMI  A. 

Some  subroutines  may  be  used  by  many  modules.  In  this  case  they  have  more 
than  one  parent  process  and  are  classified  as  "Common  Service  Routines".  These 
modules  use  the  file  name  "CSR"  followed  by  a  number  to  uniquely  identify  them  from 
other  "Common  Service  Routines".  For  example,  the  subroutine  "rand"  .  which 
generates  a  pseudo-random  number,  is  shared  by  several  modules,  therefore,  it  has  the 
file  name  "CSR5".  There  is  also  one  other  module  which  is  shared  by  the  major 
processes.  This  module  contains  giobai  data  structures  and  ;ts  file  name  is  "GLOBAL". 

The  Radar  Control  Module  also  incorporates  flies  that  contain  data  structures 
which  act  as  a  "common  memory  menace"  between  tne  major  processes.  These 
common  memory  interfaces  are  called  "tables"  and  their  'iie  names  are  the  initials 
"TAB"  followed  by  a  number  (0-77).  The  table's  file  names  are  organized  into  the 
matrix  presented  n  Tabie  2  .  This  table  shows  data  structures  which  interface  with  the 
major  processes.  The  columns  of  the  matrix  contain  entnes  which  identify  tables  usea 
as  the  input  data  structures  to  the  process  identified  by  the  letter  on  top  of  the  column. 
The  rows  of  the  matrix  contain  entries  that  identify  the  tables  which  are  used  as  output 
data  structures  from  the  process  identified  by  the  letter  in  the  left  most  column  of  the 
matrix.  For  example,  "TABS"  is  an  interface  data  structure  between  the  Radar  Return 
process  (I),  and  the  Radar  Scheduler  process  (R).  To  the  Radar  Return  process 
"TAB3"  is  an  input  data  structure  and  to  the  Radar  Scheduler  process  it  is  an  output 
data  structure. 

Since  all  the  modules  are  defined  as  Ada  packages,  some  modules  may 
incorporate  two  files,  the  package  specification  and  the  package  body.  To  distinguish 
between  them,  the  file  containing  the  specification  has  the  file  type  "LIB".  The  file 
containing  the  body  has  the  file  type  "PKG".  For  example,  the  files  "RRCM.LIB"  and 
"RRCM.PKG"  are  collectively  the  Radar  Scheduler  process.1 


1  Unless  specified  the  words  process,  module,  submodule,  subroutine,  etc.,  in  this 
thesis  refer  to  the  entire  package  data  structure. 
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TABLE  2 

COMMON  MEMORY  INTERFACE  MATRIX 


CONTROL  GROUP  I  SUPPORT  GROUP 

RSTP  IOHACBDEFKLMWX 


R 

CT 

r 

— 3" 

~T 

5 

6 

7 

"S' 

9 

10 

S 

11 

0 

12 

13 

14 

15 

16 

T 

17 

0 

18 

7 

19 

P 

20 

21 

22 

23 

24 

25 

26 

27 

10 

28 

I 

30 

31 

0 

32 

33 

34 

35 

36 

37 

38 

10 

39 

H 

40 

40 

A 

41 

42 

43 

44 

45 

46  i 

1 

47 

C 

43 

49 

50 

51 

52 

53 

■*“5 

3 

54 

r-  r* 

oo 

! 

56 

D 

57 

4 

E 

59 

| 

| 

— 

61 

1 

1 

1 

52 

52 

K 

64 

L 

65 

66 

67 

68 

M 

10 

69 

W 

70 

71 

72 

X 

73 

74 

75 

76 

77 
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III.  NPS  MODEL  OF  THE  AN/SPY-1A  RADAR  CONTROL  GROUP 


The  NPS  model  of  the  AEGIS  system  is  designed  to  emulate  the  Radar  Control 
system.  The  overall  system,  as  described  by  Gayler  [Ref.  1:  p.  1],  contains  seven 
subsystems: 

1.  Radar  System  AN/SPY-1 A 

2.  Command  and  Decision  System  MARK  1  MOD  0 

3.  Weapons  Control  System  MARK  1  MOD  0 

4.  Fire  Control  System  MARK  99  MOD  1 

5.  Guided  Missile  Launching  Svstem  MARK  26  MOD  5 

6.  Standard  Missile 

7.  Operational  Readiness  Test  System  MARK  1 

Research  at  NPS  is  focused  on  the  first  of  these  subsystems.  The  NPS  AEGIS  model 
implements  a  subset  of  the  Radar  Control  Group  subsystem,  which  in  turn  is  a  subset 
of  the  Radar  System  AN  SPY-1A.  The  reasons  for  this  decision  are  discussed  in 
Dilmore  s  thesis  [Ref.  2:  pp.  1-20|. 

The  radar  controller  modules  have  oeen  broken  down  into  two  major  groups: 
control  modules  and  support  modules.  The  control  modules  are  dedicated  to  the  five 
major  tasks  of  the  radar  controller: 

1.  Search  Management, 

2.  Radar  Scheduling, 

3.  Radar  Output, 

4.  Radar  Input  and, 

5.  Track  Processing. 

The  support  modules  perform  more  limited  or  specialized  functions.  Only  the  support 
modules  required  to  implement  the  Radar  Scheduler  will  be  presented  in  this  thesis. 

A.  RADAR  CONTROL  GROUP  MODULES 

This  section  gives  an  overall  view  of  the  Radar  Control  Group  modules  required 
for  the  modeling  of  the  Radar  Scheduler  process.  The  first  subsection  describes  the 
"control  modules"  and  the  second  subsection  is  dedicated  to  the  "support  modules". 
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1.  Control  Modules 

Four  of  the  five  "control"  modules  are  required  to  model  the  Radar  Scheduler 
functions:  the  Radar  Scheduler  process,  the  Search  Management  process,  the  Track 
Management  process,  and  the  Radar  Return  process.  Of  these  control  modules  only 
the  Radar  Scheduler  is  fully  modeled.  The  remaining  control  modules  are  at  present 
only  test  harnesses  for  the  Radar  Scheduler  process.  The  following  description  of  these 
modules  is  based  on  previous  thesis  work  [Refs.  3,5:  pp.  43-50,  32-36]. 

a.  Radar  Scheduler 

The  Radar  Scheduler's  purpose  is  to  schedule  a  mix  of  radar  events.  These 
events  actually  correspond  to  the  transmission  of  a  radar  beam  in  a  specific  direction 
for  a  certain  amount  of  time.  In  doing  this  the  scheduler  must  ensure  that  a  search 
volume  of  360  degrees  azimuth  and  90  degrees  elevation  is  covered.  The  term  "mix  of 
radar  events"  refers  die  various  types  of  events  such  as  search,  crack,  missile  control, 
etc..  Each  of  these  events  has  a  certain  priority  which  must  be  taken  :nto  account  to 
insure  its  timely  occurance.  The  time  limit  for  scheduling  a  mix  of  radar  events  in  i 
given  radar  interval  is  21  milliseconds.  For  this  reason  the  Radar  Scheduler  is  the  most 
time  critical  function  within  the  Radar  Control  Group  to  be  modeied.  A  more  detailed 
description  of  the  module’s  'unctions  will  be  given  in  the  Radar  Scneduler  Design 
chapter. 

b.  Search  Management 

The  Search  Management  module  generates  all  the  search  type  beam 
requests.  The  requests  fall  into  three  general  categories,  horizon  search,  above  horizon 
search,  and  special  request  type  beams.  The  beams  are  maintained  in  separate  queues 
in  accordance  with  the  operational  doctrine,  the  special  request  doctrine,  and  the  radar 
event  priority  list. 

The  Search  Management  module  must  insure  that  enough  horizon  and 
above  horizon  requests  are  generated  for  a  360  degree  azimuth  and  90  degree  search 
field.  These  two  event  types  may  be  considered  typical  for  normal  operation. 

On  the  other  hand,  special  request  beams  correspond  to  events  which 
would  not  be  considered  under  normal  searching  operations.  The  special  request 
category  contains  eleven  radar  event  types,  which  enhance  the  radar  search  capability. 
The  capabilities  provided  by  the  special  request  events  are  explained  in  the  remainder 
of  this  subsection. 
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Two  of  the  special  request  events  are  devoted  to  ECM  Burnthrough.  ECM 
Burnthrough  is  an  electronic  counter  measure  whereby  the  radar's  transmission  power 
is  increased  so  that  objects  can  be  seen  through  jamming  and/or  clutter.  Jamming  is  an 
electronic  warfare  technique  used  against  radar  to  distort  the  radar  return  being  viewed 
on  the  scope.  Clutter  is  a  term  used  to  describe  extraneous  blips  on  the  radar  scope. 
The  blips  are  usually  caused  by  bad  wether  or  sea  conditions. 

Special  scans  requests  are  also  controlled  by  the  Search  Management 
process.  Special  scans  include  manual  and  moving  target  indicator  (MTIJ  search 
requests.  MTI  is  a  technique  that  eiectronicaily  filters  out  stationary  objects  from  the 
radar  display,  thereby  indicating  which  objects,  or  targets,  are  actually  moving. 

The  Search  Management  module  controlls  passive  search.  In  a  passive 
search,  unlike  active  search,  the  radar's  transmitter  is  off  and  the  radar's  receiver  is 
only  used  to  detect  the  presence  of  another  emrruter. 

The  extended  search  mode  is  another  capability  that  is  controlled  by  the 
Search  Management  process.  This  is  used  when  there  are  several  contacts  along  the 
same  azimuth  and  the  radar  returns  from  the  contacts  become  difficult  to  distinguish. 
Electronic  blanking  gates  are  inserted  at  the  ranges  of  known  contacts  along  the  given 
azimuth  so  that  the  other  contacts  may  be  detected.  The  extended  search  mode  may 
aiso  be  used  to  increase  the  search  intensity  in  either  range  or  bearing. 

Horizon  confirmation  is  an  electronic  means  used  to  confirm  targets  in  a 
clutter  environment.  Horizon  confirmation  and  the  clutter  mapping  process  are  both 
supported  by  the  Search  Management  process. 

The  remaining  special  request  functions  supported  by  the  Search 
Management  module  are  missile  and  target  acquisition  requests,  and  partial  dwell 
formatting  of  the  requested  beams.  Modeling  of  the  partial  dwell  formatting  for  use  by 
the  Radar  Scheduler  would  require  the  use  of  classified  documents.  In  order  to 
maintain  the  unclassified  status  of  this  thesis,  unclassified  data  has  been  substituted  in 
the  requested  beam  queues. 

c.  Track  Management 

The  Track  Management  module  is  responsible  for  controlling  all  the 
requested  track  beams.  Controlling  the  requested  track  beams  entails  three  major  tasks, 
with  respect  to  both  real  and  simulated  targets. 

The  first  task  is  track  updating.  Track  updating  entails  an  automatic 
smoothing  of  the  position  and  rate  of  target  return  data.  This  data  is  used  to  predict 
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the  future  target  positions  with  sufficient  accuracy  to  maintain  tracking.  In  order  to 
accomplish  this,  the  Track  Management  process  must  ensure  that  the  highest  priority 
tracks  are  given  ample  illumination  time  by  the  radar  while  simultaneously  keeping 
lesser  priority  tracks  illuminated  within  the  constraints  necessary  to  maintain  their 
tracks.  When  the  system  becomes  overloaded,  the  software  must  be  able  to  compensate 
by  eliminating  those  tracks  that  are  perceived  as  least  threatening.  Naturally,  this  also 
implies  that  track  processing  must  be  able  to  evaluate  new  targets  immediately  so  that 
special  threat  candidates  and  target  splits  can  be  identified. 

The  second  task  is  track  handling.  Track  handling  includes  the  following: 

1.  Track  dwell  wave  form  selection, 

2.  Cross-gate  preparation, 

3.  Transition  from  search  to  track  mode, 

4.  Acceleration  limiting  processing,  and 

5.  Automatic  special  mode  processing. 

The  third  task  is  special  processing.  Special  processing  is  a  collection  of 
routines  used  for  MTI  tracks,  missile  tracks,  and  clock  updates.  Special  processing  also 
includes  a  routine  for  handling  spiit  targets.  A  split  target  is  actually  two  or  more 
targets  that  initially  appear  as  one  because  they  are  so  close  together.  When  the  mrget 
does  split  into  multiple  tracks  each  must  be  individually  processed. 

Special  processing  also  includes  a  routine  for  processing  Sensitivity  Time 
Control  (STC)  data.  STC  is  an  electronic  adjustment  to  the  gain  of  the  radar  receiver 
based  on  the  radar  range  to  the  target.  This  keeps  objects  closest  to  the  radar,  which 
provide  very  strong  returns,  from  saturating  the  radar  returns. 

In  conjunction  with  the  three  functions  previously  mentioned,  the  Track 
Management  module  is  responsible  for  notifying  Command  and  Decision  (C  &  D)  and 
Weapons  Control  Systems  (WCS)  of  new  tracks  and  any  special  threats. 
d.  Radar  Return  {Input) 

The  Radar  Return  module  performs  the  initial  processing  on  the  raw  data 
received  from  the  SPY-1A  Signal  Processor.  This  includes  data  validity  checks,  clutter 
mapping,  search  processing,  track  angle  error  correction,  and  ECM  analysis. 

Once  this  is  accomplished,  the  radar  data  must  be  routed  to  the  appropriate 
modules  for  further  processing.  Evaluation  and  dissemination  of  this  data  is  subject  to 
the  same  21  millisecond  time  constraint  as  the  Radar  Scheduler.  In  fact  the  Radar 
Scheduler  relies  on  synchronization  data  from  the  Radar  Return  module  to  maintain 
scheduling  interval  synchronization  with  the  radar  hardware. 
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2.  Support  Modules 

There  are  fifteen  "support  modules"  contained  in  the  Radar  Control  Group 
Modules.  These  support  modules  function  as  background  processes  to  provide  support 
for  the  "control  modules".  Seven  of  these  modules  are  required  for  modeling  the  Radar 
Scheduler  function.  The  description  of  these  modules  is  based  on  information  supplied 
in  previous  thesis  research  for  the  AEGIS  Modeling  Group  [Refs.  5,3:  pp.  36-40, 
51-55]. 

a.  Switch  Action  and  Display 

The  Switch  Action  and  Display  module  acts  as  an  interface  between  the 
Radar  System  Controller  (RSC)  and  the  radar.  This  allows  the  RCS  to  monitor  and 
control  the  radar  in  accordance  with  operational  doctrine  and  the  individual  desires  of 
the  operator. 

The  module  provides  information  to  the  Radar  Scheduler  function  which  is 
used  in  formatting  selected  beams  for  the  current  scheduling  interval.  The  information 
consists  of  inhibited  radiation  regions  and  the  radiation  power  level  (low  or  high). 
Radiation  inhibit  regions  are  regions  where  doctrine  control  does  not  allow  radar 
transmission.  The  regions  are  defined  via  start  and  stop  bearings. 

b.  Command  and  Decision  User  Services 

The  Command  and  Decision  User  Services  module  acts  as  an  interface 
between  the  Radar  Control  Group  and  the  Command  and  Decision  Group.  The 
purpose  of  the  module  is  to  check  and  route  all  the  messages  between  these  programs. 
To  accomplish  this,  a  priority  level  message  scheme  is  used  in  order  to  meet  the 
required  track  report  interval  rates  and  other  report  rates  during  peak  radar  load 
periods. 

c.  Beam  Stabilization 

The  Beam  Stabilization  module  performs  two  main  functions.  First  it 
transforms  the  ship's  motion  matrix  (roll,  pitch,  and  yaw)  into  a  stable  space  matrix 
which  is  used  for  radar  beam  guidance.  Second,  it  assigns  the  array  face  limits  which 
are  used  in  formatting  scheduled  dwells. 

The  fore  and  aft  gyro  data  converters  supply  the  necessary  roll,  pitch,  and 
yaw  information  along  with  ship's  heading  for  stabilization.  This  information  is  used 
to  compute  the  stable  deck  space  matrix. 

The  ship's  motion  matrix  and  the  bearing  limits  for  the  four  phased  array 
antennas  are  passed  to  the  Radar  Scheduler.  The  Radar  Scheduler  then  uses  the 
information  to  format  the  selected  dwells. 
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d.  Detection  Processing 

The  Detection  Processing  module  is  executed  only  when  target  or  beacon 
detection  data  is  received  from  the  Radar  Return  module.  When  this  occurs  the 
module  looks  for  detections  as  a  result  of  normal  search  (clear  and  MTI),  extended 
range  search,  horizon  confirmation,  missile  acquisition,  and  target  acquisition  dwells. 
The  module  is  also  responsible  for  initiating  track  requests  and  preparing  detections  for 
cross-gating. 

The  Track  File  data  is  maintained  by  the  Detection  Processing  module.  The 
Track  file  is  a  linked  list  data  structure  capable  of  handling  as  many  targets  as  can  be 
tracked  within  the  hardware  constraints  of  the  computer.  Access  to  the  Track  File  is 
provided  to  the  Radar  Scheduler  by  the  Track  Management  module  via  an  index  into 
the  file. 

e.  Frequency  \lanagement 

The  Freuuency  Management  module  is  used  fo  assign  radar  frequencies  to 
the  dwells  selected  by  the  Rauar  Scheduler  during  each  scheduling  interval.  The 
frequencies  and  onase  codes  assigned  to  the  dwell  are  made  to  conform  with  sector  and 
global  doctrines. 

In  accordance  with  the  doctrines,  frequency  channel  selections  are  in  one  of 

three  modes,  fixed,  random,  or  prelook.  Fixed  implies  one  designated  channel  only.  The 
random  mode  means  that  frequencies  are  selected  on  a  random  basis  from  the  available 
channels  established  by  the  current  doctrine.  Prelook  implies  frequency  selection  of  the 
least  jammed  channel  frequency  based  on  the  results  of  a  passive  angle  track  (PAT) 
frequency  analysis.  By  use  of  these  frequency  channel  selection  modes  the  Frequency 
Management  module  can  generate  the  Radar  Scheduler  input  data  for  the  frequency 
operating  channel  and  subpulse-frequency  order  selection. 

The  phase  code  to  be  used  wathin  each  dwell  is  also  specified  by  this 
module.  The  phase  codes  are  selected  at  random  from  a  list  of  the  phase  codes 
available  during  the  current  schedule  for  each  dwell.  A  separate  list  of  phase  codes  are 
maintained  for  clear  and  MTI  type  dwells. 

Each  scheduled  dwell  will  contain  channel  frequency,  band  frequency, 
phase  codes,  and  inhibited  frequency  channels.  If  the  dwell  is  an  MTI  type  then  it  will 
also  contain  MTI  frequency  data.  If  the  dwell  is  a  missile  type  then  missile  uplink  and 
downlink  frequencies  will  be  included. 
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f.  Load  Evaluation 

The  Load  Evaluation  module  provides  system's  load  information  to  the 
Command  and  Decision  element  as  well  as  the  Radar  System  Controller.  The  systems 
load  is  based  on  seven  indicies  which  must  be  computed  periodically.  These  seven 
indicies  are: 

1.  Transmitter  utilization  load, 

2.  Control  group  track  file  load, 

3.  Control  group  computer  processing  load. 

-1.  Search  frame  time  for  horizon  and  above  horizon  scans. 

5.  Track,  time. 

6.  Track  transition  index,  and 

7.  Radar  time  utilization  index. 

The  trac:x  time  variable  is  used  by  the  Rauar  Scheduler  as  input  to  reset  its' 
track  time  counter.  The  Radar  Scneuuler  keeps  a  running  cotai  of  track  time.  The 
Track  time  index  provides  the  percentage  of  radar  usage  dedicated  to  tracking  targets 
over  an  average  five  second  time  span. 

g.  Missile  Communication 

The  Missile  Communication  moduie  provides  an  interface  between  the 
Weapons  Control  System  guidance  command  generation  and  Rauar  Control  Program's 
guidance  control  link.  Uplink  missile  guidance  commands  and  the  missile  identification 
code  are  sent  to  the  Radar  Scheduler.  Further  information  on  the  operation  of  this 
function  can  be  found  in  classified  documents. 
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IV.  RADAR  SCHEDULER  DESIGN 


The  design  of  the  Radar  Scheduler  function  is  based  on  the  PL/I-80  version 
implemented  by  Grant,  [Ref.  5:  p.  41].  This  chapter  presents  the  design  details  for  the 
JANUS/ADA  version  of  the  Radar  Scheduler  process. 

A.  PURPOSE  OF  RADAR  SCHEDULER 

The  Radar  Scheduler's  purpose  is  to  schedule  a  mix  of  radar  events  (dwells)  in  a 
way  that  ensures  the  occurrence  of  necessary  events  in  a  timely  manner.  The  various 
types  of  radar  events  used  in  this  model  were  taken  from  open  literature,  rather  than 
the  actual  classified  list  found  in  the  AEGIS  performance  specifications.  [Ref.  5:  p  41] 
The  list  of  radar  events  shown  in  Table  3  are  the  radar  events  used  in  this  mode;. 


1 

t 


TABLE  3 


RADAR  EVENT  PRIORITY  LIST 


PRIORITY  RADAR  EVENT 


QUEUE  IDENTITY 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 


ECM  Burnthrough  Special  Request 
Target  Definition  Special  Request 
Special  Test  Special  Request 
Engaged  Hostile  Target  Track 
Own  SM-2  Missile  Guidance  Missile 
Pre-Engaged  Hostile  Target  Track 
High  Priority  Track  Transition  Track 
High  Priority  Track  Confirmation  Track 
Horizon  Search  Search 
Special  ECM  Burnthrough  Special  Request 
Special  Target  Definition  Special  Request 
Special  Scans  ( MTI , Man , etc )  Special  Request 
Special  Target  Acquisition  Special  Request 
Confirmed  Hostile  Track  Track 
Assumed  Hostile  Track  Track 
Unevaluated  Track  Track 
Controlled  Friendly  Track  Track 
Track  Confirmation  Track 
Track  Transition  Track 
Assumed  Friendly  Track  Track 
Confirmed  Friendly  Track  Track 
Above  Horizon  Search  Search 
Above  Horizon  Search  Test  Special  Request 
Simulation  Dwell  Special  Request 
Diagnostic  Dwell  Special  Request 
Dummy  Dwell  Special  Request 
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The  actual  mix  of  radar  events  that  get  scheduled  is  determined  by  the  Radar 
Scheduler.  The  schedule  is  governed  by  the  radar  resources  available,  time  constraints, 
and  an  event's  priority  relative  to  the  other  events  that  are  being  requested.  The  details 
of  the  process  are  explained  in  the  following  section.  The  Radar  Scheduler's 
algorithmic  description  is  given  Figure  4.1  . 


Begin  Radar  Scheduler; 

For  number  or  intervals  loop; 

Advance  radar  loon  event  counts; 

Get  value  of  real*  time  (CSR7); 

Swap  external  dwell  buffers  (RSM2); 

Do  enhancement  of  Radar  Event  Priorities  (RSM3); 
Resynchronize  computer  and  radar  times  (RSM4); 

Begin  beam  selection 

Traverse  the  Priority  List 
Traverse  the  event  queue 
If  search  or  special  request  queue  then 
Put  beam  information* in  Control  Table; 

Do  Supplementary  Dwell  Processing  (RSM6); 

Do  Face  Assignment  <RSM7); 

Do  Radar  Doclrine  (RSM8); 

Satisfy  Hardware  Constraints  (RSM9); 

If  satisfied  then 

Fill  External  Tables  (RSM10); 

Insert  Dwell  in  Control  Table  list  (RSM5); 
Else 

Delete  Dwell  from  Control  Table  list  (RSM5); 

Else 

Put  beam  information  in  Control  Table; 

Do  Supplementary  Dwell  Processing  (RSM6); 

Do  Face  Assignment  (RSM7); 

Do  Radar  Doctrine  (RSM8) j 

Satisfy  Hardware  Constraints  (RSM9); 

If  satisfied  then 

Fill  External  Tables  (RSM10) ; 

Insert  Dwell  in  Control  Table  list  (RSM5); 
Else 

Delete  Dwell  from  Control  Table  list  (RSM5); 
End  Traverse  the  Event  Queue; 

Compute  Elapsed  Time  (RSM12); 

End  Traverse  Priority  List; 

End  Beam  Selection; 

If  interval  results  are  to  be  displayed  then 

Display  Interval  Scheduling  Results  (RSM13) ; 

Free  Control  Table  Memory  for  Next  Interval  (RSM14); 

End  For  number  of  intervals  loop; 

End  Radar  Scheduler; 


Figure  4.1  Radar  Scheduler  Algorithm. 
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B.  FUNCTIONAL  DESCRIPTION  OF  RADAR  SCHEDULER 


The  Radar  Scheduler  operates  in  a  continuous  loop  selecting  requested  beams, 
generated  by  the  Search  and  Track  management  processes,  for  scheduling.  Once 
selected,  the  beams  are  formated  into  dwells.  If  the  hardware  and  other  constraints  are 
satisfied,  then  scheduled  dwells  are  sent  to  the  Radar  Output  function  and  are  packed 
into  the  Channel  Output  Buffer  for  transmission  to  the  Signal  Processor.  The  time  it 
takes  to  complete  this  task  is  defined  as  a  scheduling  interval.  Furthermore,  the  median 
scheduiing  interval  is  defined  to  be  21  bms  (binary  milliseconds). 

The  requested  beams  are  stored  for  use  by  the  Radar  Scheduler  in  four  types  of 
queues.  The  searcn  and  special  request  type  queues  are  maintained  by  the  Search 
Management  Process.*  The  track  and  missile  type  queues  are  maintained  by  the  Track 
Management  Process.'  The  Radar  Scheduler  gains  access  to  these  queues  through 
pointers  m  the  Priority  Event  List.  The  Priority  Event  List  in  turn  provides  the 
scheduler  with  a  mechanism  for  prioritizing  the  requested  beams  (see  Table  3). 
Therefore,  an  ordering  of  the  beams  is  developed  n  two  ways.  From  the  aueue 
structure  they  are  ordered  in  a  drsc  come  first  served  fashion.  Second,  the  queues 
themselves  are  ordered  by  association  with  the  Priority  Event  List.  The  queue 
associated  with  the  radar  event  at  the  beginning  of  the  list  has  the  hignest  priority  as 
indicated  in  the  tabie.  Together  these  data  structures  provide  the  oasis  of  the  priority 
scheme  used  for  selecting  the  requested  beams. 

When  the  Radar  Scheduler  program  is  loaded  for  execution,  the  Priority  Event 
List  and  the  scheduler's  internal  data  structures  are  automatically  initialized.  Also 
included  in  this  initialization  are  the  data  structures  that  the  scheduler  produces. 

The  scheduling  interval  begins  after  advancing  the  event  counts  and  updating  the 
real  time.  Next  the  external  dwell  buffers  are  swapped  preparing  them  for  the  next  set 
of  dwells  to  be  scheduled.  Once  the  buffers  have  been  swapped,  the  enhancement 
procedure  modifies  the  Priority  Event  List  holding  the  requested  beams. 

The  enhancement  routine  dynamically  enhances  the  priority  of  the  events  in  the 
list  and  in  effect  changes  its  traversal  order.  Changing  the  traversal  order  of  the  events 
increases  the  probability  of  selection  for  those  requested  beam  queues  associated  with 
the  events  at  the  head  of  the  list. 


^Search  and  special  request  queues  are  formed  from  the  Search  Node  data 
structure. 

Track  and  missile  queues  are  formed  from  the  Track  Node  data  structure. 
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After  enhancement  and  resynchronization  of  computer  and  radar  times,  the  beam 
selection  process  begins.  During  this  process  beams  are  considered  for  selection  by 
traversing  the  Priority  Event  List  in  its'  current  priority  order.  The  highest  priority 
beam  is  selected  first  and  so  on  until  the  resource  constraints  are  exhausted  for  that 
particular  interval. 

There  are  several  resource  constraints  that  must  be  considered.  There  must  be 
sufficient  radar  resources  available  to  handle  the  requested  beams.  The  elapsed  time  for 
the  scheduling  interval  must  be  less  than  the  allowed  elapsed  time.  The  total  dwells 
scheduled  must  not  exceed  the  maximum  allowed  during  an  interval.  The  final 
constraint  occurs  by  completely  traversing  the  Priority  Event  List  and  in  effect 
terminating  the  beam  selection  process.  If  these  constraints  are  met,  traversal  of  the 
Priority  Event  List  is  continued. 

If  the  event’s  beam  queue  is  not  empty  then  the  beam  queue  is  traversed 
processing  each  requested  beam.  First  the  beams  information  is  inserted  ;nto  a  Radar 
Event  Control  Tabie  node.  Next  supplementary  dwell  processing  occurs  in  preparation 
for  scheduling.  After  this  is  accomplished,  the  selected  beams  are  given  an  array  face 
assignment  and  a  comparison  is  done  between  me  beam's  transmission  and  the  radar 
doctnnes  that  are  in  effect.  Once  this  is  accomplished  the  beams  must  meet  the  final 
selection  criterion  of  satisfying  the  hardware  constraints. 

If  the  hardware  constraints  were  satisfied,  then  the  selected  beam  is  sent  to  the 
external  dwell  buffers,  load  evaluation  occurs,  and  the  node  is  added  to  the  Radar 
Event  Control  Table.  If  the  hardware  constraints  were  not  satisfied,  then  the  node  is 
returned  to  the  pool  of  available  Radar  Event  Control  Table  nodes  for  future  use.  The 
Radar  Scheduler  then  considers  the  next  beam  in  the  event's  request  queue,  and  so  on 
until  the  queue  is  empty. 

When  the  beams  in  the  queue  have  been  considered  the  scheduler  moves  on  to 
the  next  event  in  the  list.  This  continues  until  all  the  events  in  the  Priority  Event  List 
have  been  considered  or  the  resource  constraints  can  no  longer  be  met.  Once  this 
occurs,  the  scheduling  interval  is  completed  and  the  elapsed  time  is  computed. 

If  the  results  of  this  interval  are  requested  by  the  program  operator,  then  the 
appropriate  information  is  dumped  into  a  file  called  "RSOUT.TXT".  Then  the  memory 
is  freed  up  for  the  next  scheduling  interval  by  returning  the  nodes  that  make  up  the 
Radar  Event  Control  Table  to  the  pool  of  available  nodes. 
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The  run-time  Radar  Scheduler  model  does  not  implement  the  following  design 
time  modules:  Resynchronization  (RSM4),  Supplementary  Dwell  Processing  (RSM6), 
Radar  Array  Face  Assignment  (RSM7),  Comply  With  Radar  Doctrine  (RSM8),  and 
the  Radar  Load  Evaluation  (RSM11)  module.  Implementation  of  the  modules  that  are 
not  coded  would  require  knowledge  of  the  required  data  structure  values  to  be 
produced.  Due  to  time  constraints,  the  design  decisions  which  must  be  made  to 
produce  those  values  must  be  deferred  until  the  processes  that  will  use  them  are 
designed  and  implemented.  [Ref.  5:  pp.  46-47] 

C.  EXTERNAL  DATA  STRUCTURES 

The  external  data  structures  are  global  constants,  variables,  and  type  declarations 
which  act  as  interfaces  between  the  Radar  Scheduler  modules  and  the  other  Control 
Group  and  Support  Group  modules.  The  modules  are  referred  to  as  tables  and  are 
numbered  consecutively  from  zero  to  seventy- seven. 

A  Common  Memory  Interface  Matrix.  Table  7.  is  designed  to  be  used  as  an 
index  into  the  listing  of  the  external  data  structures  located  in  Appendix  D.  The 
applicable  data  structures  for  the  Radar  Scheduler  Module  can  be  found  by  reading 
across  row  "R"  to  locate  the  output  data  structures  and  down  column  "R"  to  locate  the 
input  data  structures. 

1.  Data  Structures  Consumed 

These  data  structures  reside  in  common  memory  and  are  declared  by  Library 
Packages  for  use  by  the  Radar  Control  processes  which  read  from  and  -write  to  them. 
The  Radar  Scheduler  uses  the  data  structures  in  the  following  tables  to  select  and 
format  dwells  during  a  scheduling  interval. 
a.  Table  0  -  Priority  Event  List 

The  Radar  Event  Priority  List  is  visible  to  the  Radar  Scheduler  (consumer), 
Search  Management  (producer),  and  the  Track  Management  (producer)  procedures 
only.  The  variable  pri_lst  is  a  one  dimensional  array  of  radar  events  which  correspond 
to  the  Radar  Event  Priority  List  depicted  by  Table  3  .  The  array  simulates  a  linked  list 
so  that  priorities  can  be  changed  dynamically  during  execution.  Each  element  in  the 
array  is  a  pointer  corresponding  to  a  unique  Radar  Event.  Each  event  contains  a 
BeamQue  which  is  a  variable  record  that  holds  a  pointer  to  a  queue  of  requested 
beams.  Although  each  queue  is  unique,  they  are  classified  as  either  search,  special 
request,  track,  or  missile  type  queues,  depending  which  Radar  Event  the  beam  queue 
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belongs  to.  The  variable  record  is  designed  to  associate  search  and  special  request 
beams  with  the  search  node  data  structure  found  in  TAB  1. LIB.  The  track  and  missile 
type  beams  are  associated  with  the  track  node  data  structure  of  TAB2.LIB.  The 
Priority  Event  List  is  the  key  to  the  selection  process.  By  placing  the  beam  queues  in 
the  Priority  Event  List,  the  requested  beams  are  prioritized  by  association  with  their 
respective  radar  events.  The  requested  beam's  priority  is  used  as  the  main  criterion  for 
selection.  Furthermore,  since  the  Priority  Event  List  is  designed  to  act  like  a  linked  list, 
the  traversal  order  can  be  changed  for  each  interval  to  ensure  the  eventual  selection  of 
the  lowest  priority  beams. 

The  constants  and  variables  defined  by  this  data  structure  are  described  as 


follows: 

•  status  is  a  boolean  flag  which  is  set  to  true  when  the  event  queue  has 
information  in  it. 

•  eventnm  is  a  string  with  the  event  name  corresponding  to  the  Radar  Event 
Priority  List  (Table'2). 

•  max_nodes  is  a  variable  representing  the  maximum  number  of  nodes  that  the 

event's  requested  beam  queue  can  hold. 

•  que  id  is  an  enumeration  tvpe  variable  corresponding  to  one  of  four  possible 
queue  types,  search  ,  special^  request  ,  track  ,  or‘  missile  . 

•  aue_Dtr  is  actuallv  a  variable  record  containing  a  pointer  to  the  first  node  in 
the  event's  reauested  oeam  queue,  if  the  aue_id  is'  a  search  or  special  request 

type  queue  then  the  pointer  Snode  is  visible,  otherwise  the  pointer  Tnode  is 
visible. 

•  enhnc  acts  as  a  flag  which  when  set  to  true  indicates  that  the  prioritv  of  the 
event  can  be  enhanced  bv  the  Radar  Scheduler  when  the  conditions  slated  in 
Radar  Scheduler  Module  3  are  met. 

•  b_pri  is  an  integer  variable  which  holds  a  constant  value  corresponding  to  the 
event's  base  priority.  This  value  is  the  same  as  the  "pri_lst"  array  s  index" value. 

•  c  pri  is  an  integer  variable  which  corresponds  to  the  event's  current  priority  as 
determined  by  Radar  Scheduler  Module  3. 

•  ltx  indicates  the  last  time  a  beam  from  this  event  was  selected  by  the  Radar 
Scheduler. 

•  alhvd_ltx  indicates  the  allowed  time  between  selection  for  this  type  of  event. 

•  slct  fig  is  a  flag  which  is  set  to  true  if  a  beam  from  this  event  was  selected 
during  the  previous  interval. 

•  nxt  is  an  integer  variable  used  as  an  index  or  pointer  to  the  next  prioritv  in  the 
pri  1st.  It's  value  can  only  be  changed  during  priority  enhancement.  The  value 

0"“acts  as  an  end  of  list  marker  in  the  same  way  that  a  null  pointer  marks  the 
end  of  a  linked  list. 

•  low_enhnc  is  a  constant  which  stands  for  the  lowest  enhancement  value,  4. 

•  max_pri  is  a  constant  which  stands  for  maximum  priority  but  is  actually  the 
maximum  number  of  events  in  the  Priority  Event  List  or  the  length  o'f  the 
pri  1st  array,  26. 
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b.  Table  l  -  Search  Node 


This  data  structure  acts  as  a  template  for  the  nodes  within  the  search  and 
special  request  beam  queues.  Table  1  also  provides  an  interface  for  the  Radar 
Scheduler  process  and  the  Search  Management  process.  The  fields  contained  in  the 
search  node  record  are  as  follows: 

•  info.mode  is  the  event  number  identifier.  It  can  have  a  unique  value  between  1 
and  26. 

•  info.bid  is  a  character  string  which  acts  as  a  unique  beam  identifier  for  scheduler 
errlciency  analysis. 

»  info.heam_posit.azim  is  an  integer  variable  describing  the  reauested  beams 

azimutn  position  in  deck  space  coordinates. 

•  info.beam_posit.elev  is  an  integer  variable  describing  the  reauested  beams 
elevation  posicion  in  deck  space  coordinates. 

•  info.inst_rge  is  a  variable  which  gives  an  indication  of  the  range  to  which  the 
search  beam  is  to  be  effective. 

•  info.stc  data  is  the  sensitivity  time  control  variable.  This  is  used  as  an  indication 
of  howTnucn  power  will  be  allowed  to  be  used  to  pull  contacts  out  oi  ciutter. 

•  ;nfo.aoct_blnk_gte  holds  the  vaiue  for  the  radar  doctrine  range  sate. 

•  info.citrjfmkjgte  noids  the  vaiue  for  rhe  radar  ciutter  range  gate. 

»  info.eof  innic  is  a  flag  winch  when  set  to  true  ndicates  that  :'earch  frame  uis 
been  completed.  A  search  frame  consists  of  360  degrees  of  azimuth  and  bo 
degrees  of  elevation. 

»  info.reqid  is  used  to  hold  the  identitv  of  the  requesting  process  for  special 
requestbeams. 

•  nxt  is  a  pointer  to  the  next  node  in  this  queue,  which  is  a  linked  list  of  Search 
Nodes. 

c.  Table  2  -  Track  Node 

This  is  a  common  memory  interface  data  structure  between  the  Radar 
Scheduler  process  (consumer)  and  the  Radar  Return  process  (producer)  only.  The  track 
Node  is  a  template  for  the  nodes  within  track  and  missile  beam  queues.  The  data  fields 
declared  in  the  Track  Node  are: 

•  info.mode  is  the  event  number  identifier.  It  can  have  a  unique  value  between  1 
and  26. 

•  info.bid  is  a  character  string  which  acts  as  a  unique  beam  identifier  for  scheduler 
efficiency  analysis. 

•  info.p  trk  is  a  pointer  to  the  Track  File  which  this  node  is  requesting  a  beam 
for.  The  Track  File  data  structure  is  located  in  Table  7. 

•  nxt  is  a  pointer  to  the  next  Track  Node  in  this  queue,  which  is  a  linked  list  of 
Track  Nodes. 
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d.  Table  3  -  I  to  R 


Table  3  is  a  common  memory  interface  data  structure  for  the  Radar 
Scheduler  (consumer)  and  Radar  Return  (producer)  processes.  The  data  structure  the 
following  SPY-1  radar  status  variables: 

•  resynch  time  is  the  amount  of  time  that  the  Radar  Scheduler  is  out  of 
synchronization  with  the  SPY-1  radar  expressed  in  milliseconds. 

•  loop_con  is  an  inte2er  variable  used  to  tell  the  Radar  Scheduler  how  far  ahead 
or  behind  in  the  radar  control  loop  the  Radar  Control  Program  is. 

•  xmsn_status  is  a  boolean  variable  indicating  the  transmission  status  of  the 
previous  interval's  scheduled  beams. 

e.  Table  •/  -  A  to  R 

Table  -  is  a  common  interface  data  structure  between  the  Detection 
Processing  Process  (consumer).  Radar  Scheduler  Process  (consumer),  and  the  Switch 
Action  and  Display  Process  (producer).  The  data  structure  contains  RCS  commands  to 
aid  in  the  formating  of  the  radar  dweil  buffer.  The  data  lieids  are  as  follows: 

»  power  fig  is  a  oooiean  variable  that  represents  the  status  of  the  radar  power, 
when  'power_tlg"  is  set  to  true,  the  power  is  to  hiah.  and  when  it  is  set  to  false, 
the  power  is  to  Iowa 

•  rad  pwr_ontion  is  a  boolean  variable  that  represents  the  status  of  the  radar 
power  option.  When  set  to  true  the  power  option  is  on,  and  when  set  to  false 
the  power  option  is  off. 

’  rad  iniiibt  regions  is  a  five  element  arrav  of  records  containing  start  and  stop 
Gearings  for  one  or  five  possible  radiation  inhibition  regions  definable  by 
doctrine. 

•  rad_inhibt_regions(  ).start_bng  is  the  bearing  start  indicator. 

•  rad_inhibt_regions(  ).stop_bng  is  the  bearing  stop  indicator. 

•  op  doct.mtrks  is  the  maximum  number  of  tracks  to  be  initialized  in  the  Track 
Pile.  This  value  is  used  to  aid  in  testing  the  Radar  Scheduler  Module. 

•  op  doct.mintvls  is  the  maximum  number  of  scheduleing  intervals  to  be  run  on  a 
tesl  of  the  Radar  Scheduler  Model. 

•  op_doct.dply  rect  is  an  integer  variable  used  to  define  the  interval  display  delay 
period. 

/.  Table  5  -  Command  and  Decision  User  Services  Interface 

Table  5  is  visible  to  the  Radar  Scheduler  Process  (consumer)  and  the 
Command  and  Decision  User  Services  Process  (producer).  The  interface  contains  one 
variable  to  communicate  the  transmission  status: 

•  rdr_silence  is  a  boolean  variable  w’hich  when  set  to  true,  informs  the  Radar 
Scheduler  that  radar  silence  is  in  effect. 
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g.  Table  6  -  Beam  Stabilization  Interface 

Table  6  is  a  common  memory  interface  between  the  Radar  Scheduler 
Process  (consumer)  and  the  Beam  Stabilization  Process  (producer).  The  data  structure 
contains  information  concerning  array  face  limits  and  the  ship's  motion  matrix.  The 
data  fields  are  as  follows: 

•  face  antenna  limits  is  a  four  element  array  of  records  containing  the  left  and 
right-  for  each-  of  the  four  phased  array  antenna  faces. 

•  face_antenna  limitsf  ).limit  left  indicates  the  left  most  .bearing  limit  to  an 
accuracv  of  ill  degrees  for  the  phased  arrav  antenna  face  indicated  bv  the  arrav 
index.  The  limits  “are  converted  into  stable  space  bearings  from  deck  space 
bearings  by  the  gyro  converters. 

•  face  antenna_limits(  ).right_limit  is  the  same  as  above  onlv  pertaining  to  the 
right"  most  limit. 

•  ships_motion_matrlx.x  ship  dot  is  the  value  of  the  ship's  velocity  in  the  x  deck 
direction. 

•  ships  motion  matrix.v  ship_dot  is  the  value  of  the  ship's  velocity  in  the  v  deck 
direction. 

•  ships_motion_matrL\.roll  is  the  amount  of  roll  the  ship  is  experiencing. 

•  ships_moiion_rnatrix.  pitch  is  the  amount  of  pitch  the  snip  is  experiencing. 

«  ships_motion_matrix.ya\v  is  the  amount  of  yaw  the  ship  is  experiencing. 

•  azimJimit_sione  is  the  limiting  vaiue  of  the  rise  in  elevation  for  a  given  azimuth. 

h.  Table  7  -  Track  File 

Table  7  is  a  common  memory  interface  between  the  Radar  Scheduler 
Process  (consumer/producer),  the  Detection  Processing  Process  (producer),  Track 
Processing  Process  (producer/consumer),  and  the  Track  Management  Process 
(consumer).  The  Track  File  acts  as  a  memory  map  which  allows  dynamic  allocation  of 
memory  for  tracks  as  they  are  acquired.  The  files  are  arranged  in  a  linked  list  of  track 
file  nodes.  The  track  file  nodes  contain  two  major  hierarchy  levels  beam  data  and  track 
data.  These  data  fields  are  defined  as  follows: 

•  beam  data.mode  is  an  integer  between  1  and  26  which  corresponds  to  the 
identity  of  the  radar  event  for  this  track. 

•  beam  data.bid  is  a  character  string  which  uniquely  identifies  the  requested  beam 
for  this  track. 

•  beam_data.priority  is  an  integer  value  corresponding  to  the  relative  priority  of 
this  track  compared  to  the  other  tracks  in  this  Track  File. 

•  beam_data.posit.x  is  the  rectangular  X  coordinate  of  the  track  position  as  found 
when  it  was  last  illuminated  by  the  radar. 

•  beam_data. posit. y  is  the  rectangular  Y  coordinate  of  the  track  position  as  found 
when  it  was  last  illuminated  by  the  radar. 

•  beam  data.posit.z  is  the  rectangular  Z  coordinate  (elevation)  of  the  track 
position  as  found  when  it  was  last  illuminated  by  the  radar. 
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•  beam_data.posit.slnt_rge  is  the  straight  line  range  to  the  track's  last  position. 

•  beam_data.posit.x_dot  is  the  track's  velocity  in  the  X  direction. 

•  beam_data.posit.y_dot  is  the  track's  velocity  in  the  Y  direction. 

•  beam_data.posit.z_dot  is  the  track's  velocity  in  the  z  direction. 

•  beam_data.posit.rge_dot  is  the  tracks  relative  change  in  straight  line  range. 

•  beam  data.trk  xsitn  flag  is  a  boolean  variable  which  when  set  to  true  indicates 
that  fhe  trackThas  alrack  historyless  than  or  equal  to  four  detections. 

•  beam_data.ctl_grp_trk_num  is  a  number  which  corresponds  to  the  track's  Radar 
Control  Group  track  number. 

•  beam_data.ctsl  is  a  number  used  to  historically  record  the  track. 

•  beam  data.xgte  bin_num  is  a  number  which  corresponds  to  the  track's  location 
in  the" cross-gating  matrix. 

•  beam_data.pred_azim  is  a  bearing  value  corresponding  to  where  the  track  is 
predicted  to  be  bv  the  Radar  Scheduler  upon  scheduling  a  track  dwell  on  this 
track. 

•  beam_data.pred_elev  is  the  predicted  elevation  of  the  track. 

•  beam  data.Iow_eiev  trk_tlg  is  set  to  true  when  the  track's  elevation  is  below  a 
preset"  altitude.  The-; actual  settings  are  classified. 

•  beam_data.log  ampld  est  is  an  estimate  of  the  return  signal  strength  of  the  radar 
echo  "6ouncea~otf  this  track. 

•  beam_data.xmit_req_flg  is  a  boolean  variable  which  when  set  to  true  indicates 
TraclT Processing  is  requesting  a  dwell  be  transmitted  for  this  track. 

•  beam_data.sim  tgt_flg  is  a  boolean  variable  which  is  set  to  true  when  the  track 
is  a  simulated  Target. 

•  nxt_trk  is  a  pointer  to  the  next  track  node  in  the  Track  File.  The  data  fields 
associated  with  this  pointer  are  defined  by  the  declarations  in  Table  2. 

i.  Table  8  -  Frequency  Management  Interface 

Table  8  is  used  by  the  Radar  Scheduler  Process  (consumer)  to  complete 
formatting  of  selected  radar  dwells.  The  data  structure  contains  frequency  and 
waveform  information  in  the  following  fields: 

•  waveform  is  an  array  from  1  to  "max_dwells''  of  records  containing  waveform 
information. 

•  waveform(  ).freq_chnl  is  the  channel  frequency  to  be  used  by  this  beam. 

•  waveform(  ).freq_band  is  the  frequency  band  to  be  used  by  this  beam. 

•  waveform(  ).phasel_code  is  the  frequency  phase  code  used  for  transmitting  this 
beam. 

•  waveform(  ).phase2_code  is  the  second  half  of  the  frequency  phase  code  used  for 
transmitting  this  beam. 

•  waveform(  ).mti.pri  is  the  PRI  code  used  when  the  beam  is  an  MTI  beam. 

•  waveform(  Tmti.dwl  length  is  the  length  or  duration  of  the  dwell  in 
microseconds  if  the  beam  is  a  MTI  beam. 
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•  waveform!  Tmsle.uplnk  freq  is  the  frequency  used  to  communicate  with  own 
ship's  S.M-2  missile,  if  the  beam  is  a  missile  communication  beam. 

•  waveform(  ).msle.d>vn  freq  is  the  frequency  used  by  the  missile  to  transmit 
information  back  to  the  ship,  when  the  beam  is  a  missile  communication  beam. 

•  \vaveform(  ).inhib_freq_chnl  are  the  frequency  channels  which  are  prohibited  to 
this  beam. 

j.  Table  9  -  L  to  R 

Table  9  is  the  common  memory  interface  between  the  Radar  Scheduler 
Process  (consumer)  and  the  Load  Evaluation  Process  (producer).  This  data  structure  is 
used  by  the  Radar  Scheduler  Process  to  format  track  dwells  and  contains  oniv  one  data 
field: 

•  trk  tim  ctr  reset  is  a  boolean  variable  which  when  set  to  true  informs  the 
Rauar  Scheuuier  Process  to  zero  out  its  track  time  counter. 

k.  Table  10-  Missile  Downlink  Interface 

Table  iO  is  the  common  memory’  data  structure  between  the  Radar 
Scheduler  Process  (consumer)  and  the  Missiie  Communications  Process  (producer). 
Since  the  actual  data  fields  are  eiassineu.  the  uowniinK  message  is  arbitrarily  separated 
into  eight  parts  as  follows: 

4  mssi  dwnink  is  an  array  form  one  to  'num_mssl_ms2s"  of  records  containing 
missile  messages. 

’  mssi_dwnink(  ).prtj>ne  is  an  integer  variable. 

•  mssl_dwnlnk(  ).prt_t\vo  is  an  integer  variable. 

•  mssl_dwnlnk(  ).prt_three  is  an  integer  variable. 

•  mssl_dwnlnk(  ).prt_four  is  an  integer  variable. 

•  mssl_dwnlnk(  ).prt_five  is  an  integer  variable. 

•  mssl_dwnlnk(  ).prt_six  is  an  integer  variable. 

•  mssl_dwnlnk(  ).prt_seven  is  an  integer  variable. 

•  mssl_dwnlnk(  ).prt_eight  is  an  integer  variable. 

2.  Data  Structures  Produced 

These  data  structures  are  located  in  common  memory.  They  are  used  by  the 
Radar  Scheduler  Process  (producer)  and  those  processes  which  are  consumers  of  the 
data. 

a.  Table  11  -  Search  Management  Interface 

Table  11  is  the  common  memory  data  structure  interface  between  the 
Radar  Scheduler  Process  (producer)  and  the  Search  Management  Process  (consumer). 
The  data  structure  is  used  by  the  Search  Management  Process  to  distinguish  which 
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search  queues  require  filling.  The  Radar  Scheduler  sets  the  flags  when  it  has  used  a  set 
number  of  search  request  beams.  The  flags  are  defined  below: 

•  hs_que_replen  is  a  boolean  variable  which  when  set  to  true  indicates  that  the 
hoTizon  search  queue  needs  to  be  replenished. 

•  ahs_que_replen  is  a  boolean  variable  which  when  set  to  true  indicates  that  the 
above  horizon  search  queue  needs  to  be  replenished. 

b.  Table  17  -  Track  Management  Interface 

Table  17  is  the  common  memory  data  structure  between  the  Radar 
Scheduler  Process  (producer)  and  the  Track  Management  Process  (consumer).  The 
Radar  Seneduler  Process  uses  the  data  structure  to  hoid  the  scheduled  track  dwells 
selected  for  transmission.  The  Tracic  Management  Process  uses  the  data  structure  to 
asses  its  efficiency  in  prioritizing  previously  requested  tracks.  The  data  fields  are 
defined  as: 

•  sched_trk_beamjist  is  an  array  from  one  to  -max_dweiis"  of  records. 

•  sched  trk  beam  iisr(  ).mode  id  is  a  mteaer  variable  used  to  identify  the  radar 
event*ass6eiatecfwith  the  scheduled  track! 

»  sched  trk  beam  fist!  ).trk  file  num  is  the  unique  track  number  of  the  scheduled 
track." 

»  sched_trk_beamjist(  ). priority. 

c.  Table  0  -  Track  Processing  Interface 

Tabie  20  is  a  common  memory'  interface  used  ov  the  Radar  Scheduler 
Process  (producer)  and  the  Track  Management  Process  (consumer).  The  data  structure 
contains  information  on  each  of  the  scheduled  dwells  for  one  scheduling  interval.  As 
dwells  are  formatted  for  transmission,  the  Radar  Scheduler  Process  transmits  the 
information.  The  data  fields  are  defined  as  follows: 

•  stble_spc_pos  is  an  array  from  one  to  "max_dwells"  of  records  containing  stable 
space  position  information. 

•  stble_spc_pos(  ).azim  is  the  bearing  of  the  scheduled  dwell  in  tenths  of  degrees. 

•  stble_spc_pos(  ).elev  is  the  elevation  of  the  scheduled  dwell  in  tenths  of  degrees. 

•  stble_spc_pos(  ).x_posit  is  the  rectangular  X  coordinate  of  the  scheduled  dwell. 

•  stble_spc_pos(  ).y_posit  is  the  rectangular  Y  coordinate  of  the  scheduled  dwell. 

•  stble_spc_pos(  ).z_posit  is  the  rectangular  Z  coordinate  of  the  scheduled  dwell. 

•  sched  xmsn_time  is  the  scheduled  transmission  time  in  milliseconds  for  the 
scheduled  dwell. 

d.  Table  32  -  Radar  Output  Interface 

Table  32  is  the  common  memory  interface  between  the  Radar  Scheduler 
Process  (producer)  and  the  Radar  Output  Process  (consumer).  It  acts  as  a  buffer  for 
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the  formatted  dwells,  and  supplies  information  to  the  Radar  Output  Process  to  aid  in 
completing  the  channel  I/O  control  buffer.  The  data  structures  in  Table  32  are  defined 
as  follows: 

•  ptr_r  to_o  is  a  two  element  array  of  pointers  used  to  access  two  linked  lists  of 
records  containing  dwell  data. 

•  ptr_r_to_°(  ).d>vl_data.mode  is  the  major  transmission  mode  used  by  this  dwell. 

•  ptr_r_to_o(  ).dwl_data.face  is  the  antenna  face  assigned  to  this  dwell. 

•  ptr_r  to_o(  ').dwl_data.sub_mode  is  a  two  element  array  of  integers  which  are  the 

frequency  sub- modes  assigned  to  this  dwell. 

•  Ptr_r  to_o{  >.d\vl  data.d\vl_idx  is  the  dwell  index  number  for  the  current 

scheduling  interval. 

•  Ptr_r_to_°(  ).d>vl_data.beam  purpose  is  an  integer  which  corresponds  to  the 
beam  s  mode  value  which  indicates  what  purpose" the  dwell  was  scheduled  for. 

•  p.tr  r  to_o(  ).d\vl  data.dw]  start_idx  is  a  32  bit  number  which  is  the  transmission 
time  Tor  the  dwell  to  an  accuracy  which  is  classified. 

•  ptr  r_to_o(  ).d\vi_data.doct_unblnk  gates  data  has  been  read  from  the  Search 
Management  provided  data. 

•  ptr  r  to  of  ).dwl  data.clutter  unblnk  gates  data  is  the  same  form  as 

dQctj3nErmk_gates.~ 

•  Ptr_r_to_()l  )dink  is  a  pointer  to  the  next  dwell  data  record  in  the  iinked  list. 

e.  Table  40  -  Output  Control  Channel  Buffer 

Table  40  is  a  common  memory  interface  between  the  Radar  Scheduler 

Process  (producer),  the  Radar  Output  Process  (producer),  the  Radar  Control  Program, 
and  the  Radar  Channel  Control  Program  (consumer).  The  Radar  Scheduler  Process  has 
responsibility  for  filling  only  a  small  portion  of  the  data  fields  which  are  defined  below: 

•  occb_ptr  is  a  two  element  array  of  pointers  to  two  linked  lists  of  records 
containing  Output  Channel  Control  Buffer  information. 

•  occb_ptr(  ).oa.cntrl  ’vvord.rdr_xmsn_on  is  a  boolean  variable  which  wrhen  set  to 
true  indicates  that  file  dwell Ts  to  be  transmitted. 

•  occb_ptr(  ).om.face  is  the  antenna  face  assigned  to  this  dwell. 

•  occb  ptr(  ).oh.pril_mti  is  the  MTI  PRI  code  used  by  the  dwell  when  it  is  an 
MTT  dwell.  ~ 


occb_ptr(  ).oh.pri2_mti  is  the  second  half  of  the  PRI  code. 

occb_ptr(  ).ot  is  a  twelve  element  array  of  records  emulating  missile 
communications  links. 

occb_ptr(  ).otf  ).otmsb  emulates  a  missile  communication  link  when  the  dwell  is 
a  missile  dwell. 

occb_ptr(  ).ot(  ).otlsb  also  emulates  a  missile  communications  link. 

occb_ptr(  ).ol.xmit_freq  is  the  transmission  frequency  used  by  this  dwell. 

occb_ptr(  ).ol.rcm_freq  is  the  receiver  frequency  used  to  receive  the  return  dwell 
signal. 
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•  occb_ptr(  ).oj.subchnl_freq_group  is  the  group  of  sub-channel  frequencies  used  to 
transmit  this  dwell. 

•  occb_ptr(  ).o_f.phsel_code  is  the  first  part  of  the  dwell  frequency  phase  codes. 

•  occb_ptr(  ).og.fdbkl  is  the  first  part  of  the  dwell  feedback  phase  codes. 

•  occb_ptr(  ).oa.cntrl  word.freq_group_slct  is  a  boolean  flag  which  when  set  to 
true  indicates  the  selected  frequency  group  for  this  dwell. 

•  occb_ptr(  ).oi.dwl_l_start_time  is  the  start  time  for  the  dwell  in  microseconds. 

•  occb  ptr(  ).ob.detectl_thrsld  holds  the  value  of  an  expected  detection  range  for  a 
track"  type  dwell. 

•  occb_ptrf  ).ob.detect2  thrsid  holds  the  value  of  an  exoected  detection  range  for  a 
track"  type  dwell. 

•  occb  ptri  ).ob.detect3  thrsid  holds  the  value  of  an  expected  detection  ranee  for  a 
track  type  dwell. 

•  occb_ptr(  ).oe.truncl  thrsid  is  a  truncation  signal  level  threshold  value  to  assist 
in  detecting  targets. 

•  occb  ptri  ).oe.trune2  thrsid  is  a  truncation  signal  level  threshold  value  to  assist 
in  detecting  targets. 

•  occb_ptr(  ).oq.eiev_sector  is  the  sector  elevation  limits  for  this  dweil. 

•  occb_ptn  ).os.dply_azim  is  the  bearing  the  dweil  is  to  be  transmitted  on. 

•  occb  ptr(  ).o  r.dply_eiev  ts  the  elevation  this  dweil  is  to  be  transmitted  on  in 
degrees. 

•  occb_ptr(  ).os.video_extnt  is  the  signal  level  exoected  from  this  dweil. 

•  occb_ptr(  ).trk_gate_strt  is  the  starting  range  for  gating  a  track  dwell. 

•  occb  ptr(  ).link  is  a  pointer  to  the  next  Output  Channel  Control  Buffer  node 
available. 


D.  INTERNAL  DATA  STRUCTURES 

All  data  structures  that  are  internal  to  the  Radar  Scheduler  Process  and  that 
must  be  shared  by  subordinate  Radar  Scheduler  modules  are  located  in  the  package 
specification  of  RSMO.  The  data  structures  are  defined  as  follows: 

•  rdrint  is  a  constant  that  represents  the  maximum  time  which  can  be  spent  in  the 
Beam  Selection  Module. 

•  srch_que  is  a  constant  used  to  represent  the  event  type  Search. 

•  sr_que  is  a  constant  used  to  represent  the  event  type  Special  Request. 

•  trk_que  is  a  constant  used  to  represent  the  event  type  Track. 

•  mssl_que  is  a  constant  used  to  represent  the  event  type  Missile. 

•  srch  dnls  is  a  constant  equal  to  the  maximum  number  of  Search  events  that  can 
be  scheduled  in  one  interval. 

•  sr_d>vls  is  a  constant  equal  to  the  maximum  number  of  Special  Request  events 
that  can  be  scheduled  in  one  interval. 
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•  trk  thvls  is  a  constant  equal  to  the  maximum  number  of  Track  events  that  can 
be  scheduled  in  one  interval. 

•  mssl  chvls  is  a  constant  equal  to  the  maximum  number  of  Missile  events  that 
can  5e  scheduled  in  one  interval. 

•  rdr_rsrcs  is  a  constant  which  represents  the  percentage  of  radar  resources  which 
can  be  used  in  scheduling  beams  for  an  interval. 

•  ppl  is  an  integer  variable  used  as  an  index  for  traversing  the  priority  list. 

•  intvl  num  is  an  integer  variable  used  to  represent  the  number  of  intervals  that 
have“been  executed. 

The  next  data  structure  contained  in  RSM0  is  the  Radar  Event  Control  Taole. 
This  is  the  primary  data  structure  used  by  the  Radar  Scheduler  to  schedule  a  mix  of 
radar  events  lor  one  scheduling  interval.  The  Radar  Event  Control  Tabie  is  a  linked  list 
of  records.  The  records  which  act  as  nodes  contain  the  following  fields: 

•  srch  dwl  is  a  pointer  to  a  Search  Node  data  structure  described  in  externai 
Table  1. 

•  trk_dwi  is  a  pointer  to  a  Track  Node  data  structure  described  in  externai  Taole 

t  , 

•  ocb  data  is  a  record  containing  the  data  to  be  transmitted  to  the  external  dweil 
butlers.  Explanations  for  the  data  iieids  in  this  record  can  be  found  in  Sections 
IV.CC.d  arid  e. 

•  beamia  is  a  i  criaracter  string  used  for  testing  the  logic  of  the  Radar  Scheduler 
algorithm. 

**  dru  is  an  integer  also  used  for  testing  the  logic  of  the  Radar  Scheduler 

algorithm. 

•  nxt  event  is  a  pointer  which  acts  as  a  link  to  the  next  Radar  Control  Table 
node  in  the  linked  list. 

•  rect  is  a  pointer  to  the  head  of  the  Radar  Control  Table's  linked  list  data 
structure. 

•  sp  is  a  pointer  to  the  Search  Node  data  structure  described  in  Table  1. 

•  tp  is  a  pointer  to  the  Track  Node  data  structure  described  in  Table  2. 

•  rect  ptr  is  a  pointer  to  the  head  of  the  linked  list  which  makes  up  the  Radar 
Event  Control  Table. 

•  pool_ptr  is  a  pointer  to  Radar  Event  Control  Table  record. 

•  buff_ptr  is  a  pointer  to  a  the  data  structure  described  in  Table  40. 

•  cm_ptr  is  a  pointer  to  the  data  structure  described  in  Table  32. 

E.  RADAR  SCHEDULER  MODULE  DESCRIPTIONS 

The  modules  described  in  this  section  are  subordinate  to  the  Radar  Scheduler 
process.  A  functional  description  of  each  of  the  modules,  and  any  subroutines 
subordinate  to  them  is  given  below. 
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1.  Initialization 

The  function  of  the  initialization  module  is  to  create  and  initialize  any  data 
structures,  local  to  the  Radar  Scheduler  process,  that  must  be  shared  between  the 
Radar  Scheduler  modules.  The  creation  of  these  data  structures  is  necessary  only  for 
access  type  data  structures  which  form  linked  lists.  Allocation  of  memory  for  these  data 
structures  prior  to  the  execution  of  the  Radar  Scheduler  process  serves  to  increase  the 
efficiency  of  the  main  scheduling  loop  by  eliminating  the  need  to  allocate  memory  for 
each  new  node  during  scheduling.  This  module  is  executed  oniy  one  rime,  ’.v'nen  the 
Radar  Scheduler  process  is  loaded  for  execution. 

The  decision  to  place  these  variables  in  a  separate  module  instead  of  the 
package  specification  for  the  Radar  Scheduler  process  is  based  on  the  principle  of 
information  hiding.  Since  these  variables  need  to  be  shared  by  other  Radar  Scheduler 
modules  they  must  be  in  a  package  specification.  If  they  were  placed  in  die  Radar 
Scheduler  s  package  specification,  then  modules  other  cnan  Radar  Scheduler  modules 
wouid  be  able  to  access  them. 

The  initialization  mouule  does  not  consume  any  common  memory  interface 
data  structures.  It  does  produce  the  initial  pool  of  Output  Channel  Control  Duller 
nodes  and  a  pooi  of  Radar  Event  Control  Table  nodes. 

The  following  data  structures  are  declared  in  module  specification  and  are 
local  to  the  Radar  Scheduler  process: 

•  rdrinit  is  a  constant  representing  the  maximum  amount  of  time  which  can  be 
spent  in  the  beam  selection  mode. 

•  srch_que  is  a  constant  assigned  to  the  event  type  search. 

•  trk_que  is  a  constant  assigned  to  the  event  type  track. 

•  sr_que  is  a  constant  assigned  to  the  event  type  special  request. 

•  mssl_que  is  a  constant  assigned  to  the  event  type  missile. 

•  srch  dwls  is  a  constant  representing  the  maximum  number  of  search  events  that 
can  Toe  scheduled  in  one  interval. 

•  trk  dwls  is  a  constant  representing  the  maximum  number  of  track  events  that 
cari”be  scheduled  in  one  interval. 

•  sr  dwls  is  a  constant  representing  the  maximum  number  of  special  request 
events  that  can  be  scheduled  in  one  interval. 

•  mssl  dwls  is  a  constant  representing  the  maximum  number  of  missile  events  that 
can  Be  scheduled  in  one  interval. 

•  srch_pcnt  is  a  constant  representing  the  percentage  of  radar  resources  allotted 
to  each  search  dwell. 

•  trk  pent  is  a  constant  representing  the  percentage  of  radar  resources  allotted  to 
each  track  dwell. 
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•  sr_pcnt  is  a  constant  representing  the  percentage  of  radar  resources  allotted  to 
each  special  request  dwell. 

•  mssl_pcnt  is  a  constant  representing  the  percentage  of  radar  resources  allotted 
to  each  missile  dwell. 

The  following  data  structures  are  used  to  control  program  execution: 

•  ppl  is  an  index  used  to  control  traversal  of  the  priority  event  list. 

•  intvl_num  is  used  to  keep  track  of  the  number  of  intervals  that  have  been 
executed. 

•  sp  is  a  working  pointer  for  traversing  a  linked  list  of  search  nodes. 

•  tp  is  a  working  pointer  for  traversing  a  linked  list  of  track  nodes. 

•  r  is  a  working  pointer  for  traversing  the  Radar  Event  Control  Table. 

•  rect  ptr  is  a  pointer  which  alwavs  identifies  the  first  node  in  the  Radar  Event 
Control  Table 

•  pool  ptr  is  a  pointer  which  alwavs  identifies  the  first  node  in  the  pool  of 
available  Radar  Event  Control  Table  nodes. 

•  buff_ptr  always  points  to  the  current  Channel  1,  0  Control  node. 

•  cm_pir  always  points  to  the  current  Radar  Output  node. 

The  Radar  Event  Control  Table  is  the  primary  data  structure  used  by  the 
Radar  Scheduler  process  to  schedule  the  mix  of  radar  events  for  each  interval.  This 
data  structure  contains  live  major  fields: 

».  srch_dwl  is  a  mirror  imaae  of  the  search  node  aata  structure  (see  Section  C.  l.a 
of  this  cnapter). 

•.  trk  dwl  is  a  mirror  image  of  the  track  node  data  structure  (see  Section  C.l.b  of 
thirchapter). 

•.  ocb  data  contains  the  information  that  is  transmitted  to  the  external  dwell 
buffers.  An  explanation  of  the  data  fields  in  this  record  is  is  given  in  Sections 
C.2.d  and  e  of  this  chapter. 

•.  beamid  corresponds  to  the  beam  identifier  used  bv  the  srch_d\vl  or  trk_dwl  '"bid" 
data  field  and  is  used  for  testing  the  logic  of  the  Radar  Scheduler  algorithm. 

•.  dru  holds  the  total  percentage  of  radar  resources  consumed  after  the  selection  of 
the  current  beam. 

*.  axt  event  is  a  link  to  the  next  node  in  the  linked  list  that  makes  up  the  Radar 
Event  Control  Table. 

There  are  no  data  structures  locally  declared  within  this  module  body.  The 
procedures  make_pool  and  ex_buff_create  are  declared  local  to  the  module  body  and 
are  used  for  the  initialization  process.  An  algorithmic  description  of  the  Initialization 
module  is  given  in  Figure  4.2  . 

a.  Make  Pool 

The  procedure  Make  Pool  is  derived  from  the  PL/I-80  version  of  RSM1A. 
This  procedure  is  declared  within  the  body  of  the  Initialization  module  described 
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Begin  Radar  Scheduler  Initialization; 

Create  a  pool  of  Output  Channel  Control  Buffer  nodes; 
Create  a  pool  of  Radar  Output  Interface  nodes; 

Create  a  pool  of  Radar  Event  Control  Table  nodes; 
Initialize  working  pointers  for  Radar  Scheduler; 

End  Radar  Scheduler  Initialization; 


Figure  4.2  Initialization  Module  Algorithm. 

above.  The  purpose  of  this  procedure  is  to  make  a  pool  of  Radar  Event  Control  Table 
nodes. 

The  procedure  declares  two  local  pointers,  "p"  and  "q"  for  creating  a  linked 
list  of  Radar  Event  Control  Table  nodes.  The  variable  numb_nodes  stands  for  the 
number  of  nodes  to  be  created. 

b.  Create  Dwell  Buffer  Pools 

The  procedure  Create  Dwell  Buffer  Pools  is  derived  from  the  PL.  1-80 

version  of  RSM1B.  The  task  of  this  procedure  is  to  create  two  circular  linked  lists  for 

the  Output  Channel  Control  Buffer  and  two  circular  linked  lists  for  the  Radar  Output 
Interface  nodes. 

The  procedure  declares  the  following  working  pointers  locally  for  the 
purpose  of  creating  the  circularly  linked  lists: 

•  pi  and  ql  are  Output  Channel  Control  Buffer  pointers. 

•  p2  and  q2  are  Radar  Output  Interface  pointers. 

The  following  data  structures  are  used  for  execution  control  flow  within  the 

procedure: 

•  length  is  the  length  of  the  circular  linked  lists  being  created. 

•  ctr  is  a  variable  used  to  keep  track  of  the  number  of  nodes  being  created. 

•  i  is  an  index  to  control  the  number  of  circular  linked  lists  being  created. 

2.  Swap  Dwell  Buffers 

Functionally,  the  Swap  module  manages  the  Radar  Scheduler's  access  to  the 
two  external  dwell  buffers  described  above.  The  Swap  module  must  insure  that  a 
minimum  number  of  available  nodes  are  present  in  the  pool  for  consumption  by  the 
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Radar  Scheduler  during  each  scheduling  interval.  The  Swap  module  is  called  from  the 
beginning  of  the  main  control  loop  in  the  Radar  Scheduler  process. 

The  Swap  module  consumes  the  global  pointer  variables  to  the  common 
memory  interface  pools  of  Output  Channel  Control  Buffer  and  Radar  Output  nodes. 
This  module  does  not  produce  any  common  memory  interface  data  structures.  The 
algorithm  for  this  procedure  is  given  in  Figure  4.3 

The  input/output  parameters  are  the  only  data  structures  declared  locally  and 
are  passed  by  reference.  These  data  structures  are: 

•  buff  is  a  pointer  to  the  Output  Channel  Control  Buffer. 

•  cm  is  a  pointer  to  the  common  memory  interface  Radar  Output  butfer. 

•  index  is  the  index  to  the  current  buffers. 


Begin  Swap  Dwell  Buffers: 
if  the  index  is  two  men 
rhe  index  gets  one: 

else 

the  index  gets  two: 
enu  if: 

change  dwell  buffers; 
End  Swap  Dwell  Buffers; 


Figure  4.3  Swap  Dwell  Buffers  Algorithm. 

3.  Radar  Event  Priority  Enhancement 

The  function  of  this  module  is  to  ensure  that  the  mix  of  radar  events  being 
considered  for  selection  is  optimized  by  their  respective  priorities  in  the  Radar  Event 
Priority  List.  The  design  is  based  on  Digital  Equipment's  VMS  Operating  System 
Priority  Enhancement  Algorithm.  Radar  events  having  base  priorities  lower  than  the 
enhancement  value  have  the  capacity  for  dynamic  prioritization.  The  procedure 
examines  each  event  to  see  if  its  priority  can  be  enhanced.  If  the  event's  priority  needs 
to  be  enhanced,  its  priority  value  is  increased.  Execution  of  this  module  takes  place 
prior  to  the  Beam  selection  and  Synchronization.  When  executed,  the  module 
produces  a  reprioritized  Radar  Event  Priority  List.  [Ref.  5:  p.  76] 
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Begin  Priority  Enhancement; 

Reset  the  last  time  executed  for  all  radar  events; 

Traverse  the  enhanceable  portion  of  the  priority  list; 

If  the  event  is  enhanceable  and  its  queue  is  not 
empty  then 

If  the  time  between  scheduling:  of  the  event  is 
greater  than  the  allowed  time  “then 

If  the  event's  current  priority  is  above 
the  standard  enhancement  vaiue  but  below 
the  lowest  enhancement  vaiue  then 

Increment  the  event  s  priority  by  i; 

Else 

Increment  the  event's  orioritv  bv  -i  but 
not  above  the  low  enhancement  value: 

End  Enhance: 

Reorder  the  orioritv  event  list; 

End  Last  time  executed: 

End  Traverse  the  priority  list: 

End  Priority  Enhancement: 


Figure  4.4  Priority  Enhancement  Algorithm. 

The  enhancement  module  does  not  consume  any  common  memory  interface 
data  structures.  The  input  parameter  to  this  procedure  is  the  variable  elapsed_time 
which  is  passed  by  value  from  the  Radar  Scheduler  process.  The  parameter 
elapsed_time  is  used  to  update  the  Radar  Event  Priority  List  Itx  data  field.  The 
algorithm  for  the  Enhancement  module  is  presented  in  Figure  4.4 

This  module  uses  the  procedure  ripl  to  remove  and  insert  a  node  from  its 
present  position  in  the  priority  list  to  its  new  position  in  the  list.  The  procedure  is 
declared  locally  in  the  Enhancement  modules  body. 
a.  Remove  and  Insert 

The  Remove  and  Insert  procedure  is  part  of  the  Enhancement  module. 
The  procedure  removes  a  node  from  its  current  position  in  the  priority  list,  inserts  the 
node  at  its  new  priority  and  then  resets  the  current  priority  values  for  the  other  events. 

The  following  data  structures  are  declared  locally: 
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•  curnt  is  an  input  parameter  passed  by  value  representing  the  event's  current 
priority  in  the  list. 

•  new  p  is  an  input  parameter  passed  by  value  representing  the  event's  new 
priority  in  the  list. 

•  p  is  an  index  used  to  traverse  the  priority  list. 

•  b4  is  a  variable  that  holds  the  last  value  of  the  index  "p". 

•  tempi  and  temp2  are  temporary  storage  variables  for  the  indexes. 

4.  Radar  and  Computer  Synchronization 

The  function  of  this  module  is  to  ensure  that  the  Radar  Control  Group  time  is 
synchronized  to  the  radar  time.  The  scheduler  waits  for  a  clocx  update  from  the  radar. 
According  to  AEGIS  performance  specifications,  the  scheduler  must  schedule  dummy 
dwells,  if  the  update  is  greater  than  two  seconds.  The  Radar  Scheduler  design  calls  for 
the  process  to  be  "blocked”  until  synchronization  has  been  accomplished.  The 
scheduler  is  made  "ready"  upon  synchronization  of  clocks  and  Track  File  time  updates. 
The  Radar  Scheduler  must  alert  the  RSC  (or  in  our  case  the  Switch  Action  and 
Display  process)  to  the  pending  update.  This  requirement  is  not  implemented  in  this 
version  of  the  scheuuier  model.  For  dock  updates  of  less  than  two  seconds,  immediate 
synchronization  is  carried  out  and  the  the  current  scheduling  interval  is  modified  to 
conform  with  the  new  Radar  Control  Group  time.  [Ref.  5:  p.  781 


Begin  Synchronization; 

If  I  to_R.resynch_time  minus  Radar  Scheduler  time  is 
greater  than  2  seconds  then 

Wait  until  the  Radar  Scheduler  time  equals  the 
resynch_time; 

Else  if  the  resynch_time  minus  Radar  Scheduler  time  is 
greater  than  or  equal  to  zero  but  less  than  or  equal  to 
2  seconds  then 

Radar  Scheduler  time  gets  radar  time; 

End  Synchronization; 


Figure  4.5  Synchronization  Algorithm. 

This  module  consumes  the  synchronization  variable  within  the  Radar  Return 
(input)  Interface  data  structure.  It  does  not  produce  any  common  memory  interface 
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data.  Real  time  data  is  produced  for  use  by  the  Radar  Scheduler  when  a  clock,  update 
occurs. 

The  modules  local  data  structures  have  not  been  designed.  The  algorithm  for 
Radar  and  Computer  Synchronization  is  given  in  Figure  4.5  . 

5.  Beam  Selection  Routines 

This  module  contains  procedures  used  in  the  Beam  Selection  process  of  the 
Radar  Scheduler.  The  code  for  the  Beam  Selection  process  is  actually  part  of  the  Radar 
Scheduler  code  and  the  functional  description  for  Beam  Selection  is  given  there.  This 
module  is  a  package  containing  two  procedures  and  a  function.  Their  functional 
descriptions  are  given  in  the  following  subsections  of  this  section. 

This  module  contains  one  local  data  structure,  a  working  pointer  p  which  is 
used  by  the  routines  in  this  module's  body.  The  pointer  is  declared  outside  of  the 
routines  morder  to  increase  their  eificiency  and  prevent  heap  or  stack  over  flow  which 
wouid  occur  by  repeated  calls  co  these  procedures/ function. 

This  module  does  not  consume  or  produce  any  common  memory  data 
structures. 

a.  Add  Linked  List 

Functionally,  the  procedure  llend  is  used  to  insert  a  Radar  Event  Control 
Table  node  at  the  end  of  a  linked  list.  This  procedure  is  derived  form  the  PL/ 1-80 
module  RSM3A.  The  procedure  declaration  is  contained  in  the  Beam  Selection  module 
described  above. 

The  parameters  to  this  procedure  are  pointers,  q  and  s,  which  are  passed  by 
reference.  The  pointer  q  points  to  the  head  of  the  list.  The  pointer  s  points  to  the  node 
which  is  to  be  inserted  at  the  end  of  the  linked  list.  The  pointers  consumed  in  this 
procedure  are  Radar  Event  Control  Table  data  structures  local  to  the  Radar  Scheduler 
modules  only.  There  are  no  common  memory  interface  data  structures  consumed  by 
this  procedure. 

There  are  no  local  data  structures  produced  by  this  procedure.  The 
working  pointer  p  is  declared  in  the  body  of  the  Beam  Selection  Routines  module. 

The  algorithmic  description  for  this  procedure  is  given  in  Figure  4.6  . 

b.  Get  RECT  Node 

The  function  Get  RECT  Node  locates  the  first  available  Radar  Event 
Control  Table  node  from  the  pool  and  returns  a  pointer  to  that  node.  The  function 
also  resets  the  head  of  pool's  linked  list  to  the  next  available  node. 
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Begin  llend; 

If  first  list  q  is  null  then 
list  q  gets  node  s; 


Else 


Find  end  of  list  q; 

End  of  list  q  gets  node  s; 

End  llend: 


Figure  4.6  llend  Algorithm. 

There  are  no  common  memory  interface  data  structures  consumed  by  this 

procedure. 

There  are  no  local  data  structures  produced  by  this  procedure.  The 
working  pointer  p  is  declared  in  the  body  of  the  Beam  Selection  Routines  module. 

The  algorithmic  description  of  this  function  is  given  in  Figure  4.7 


Begin  Get  RECT  Node: 

If  pool  is  empty  then 

Create  a  new  pool  pointer; 

End  if; 

p  gets  pool  pointer; 

pool  pointer  gets  next  node  in  linked  list; 
Return  pointer  p; 

End  Get  RECT  Node; 


Figure  4.7  Get  RECT  Node  Algorithm. 
c.  Free  RECT  Node 

Functionally,  this  procedure  returns  an  unused  Radar  Event  Control  Table 
node  to  the  pool  of  available  nodes.  The  procedure  Free  RECT  node  together  with  the 
function  Get  RECT  Node  are  used  to  manage  pointer  storage. 
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There  are  no  common  memory  interface  data  structures  consumed  by  this 

procedure. 

There  are  no  local  data  structures  produced  by  this  procedure.  The 
working  pointer  p  is  declared  in  the  body  of  the  Beam  Selection  Routines  module. 

Figure  4.8  gives  the  algorithmic  description  of  the  procedure  Free  RECT 

Node. 


Beam  Free  RECT  Node: 

Set  node  a  s  link  to  null: 
if  pool  is  empty  then 

pool  pointer  gets  node  q; 

Else 

.nsert  node  q  at  end  or' pool  list: 
End  if: 

Ena  Free  RECT  Node: 


Figure  4.8  Free  RECT  Node  Algorithm. 

6.  Supplementary  Dwell  Processing 

The  function  of  the  Supplementary  Dwell  Processing  module  is  to  do  sufficient 
processing  on  each  selected  beam  to  ensure  enough  dwell  information  is  generated  for 
correct  transmission  by  the  radar.  The  minimum  information  required  is:  • 

•.  the  scheduled  dwell's  transmission  time, 

•.  the  dwell  index  number, 

•.  the  stable  space  bearing  and  elevation  beam  position, 

•  .  the  radar  end  the  dwell  is  to  be  transmitted  from  and, 

•.  the  radar  transmission  parameters. 

The  data  structures  used  by  this  module  have  not  been  decided  upon  [Ref.  5:  p.  82]. 

The  algorithm  for  this  module  has  not  been  written. 

7.  Dwell  Array  Face  Assignment 

The  function  of  this  module  is  to  assign  an  array  face  to  each  selected  beam. 
The  NTS  model  assumes  that  the  ship  is  not  underway  and  on  a  heading  of  000 
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degrees  true,  therefore  the  model  does  not  emulate  gyro  inputs.  Hence,  stable  space 
coordinates  equate  to  ship's  deck  space  coordinates.  The  result  of  this  is  that  the 
transformation  matrix  and  array  face  bearing  limits  generated  by  the  Beam 
Stabilization  process  are  constant.  The  Assignment  module  is  used  to  select  the  array 
face  for  the  beam's  transmission  by  comparing  the  beam's  bearing  to  the  limits  found 
in  the  array  face  bearing  limits  table.  This  assignment  consumes  the  common  memory 
interface  data  for  array  face  bearing  limits.  No  common  memory'  data  is  produced. 
[Ref.  5:  pp.  82-83] 

No  internal  data  is  consumed  by  this  module  and  there  are  no  locally  declared 
data  structures  in  this  module.  It  does  produce  the  face  assignment  data  for  the 
selected  beam  which  is  located  in  the  Radar  Event  Control  Table  data  structure. 

This  module  is  not  implemented  in  the  Radar  Scheduler  model.  An 
algorithmic  description  of  the  module  is  given  in  Figure  -1.9  . 


Begin  Dwell  Array  Face  Assignment; 

If  beam  bearing  is  between  first  limits  then 
Beam  face  assignment  gets  one; 

Else  if  beam  bearing  is  between  second  limits  then 
Beam  face  assignment  gets  two; 

Else  if  beam  bearing  is  between  third  limits  then 
Beam  face  assignment  gets  three; 

Else 

Beam  face  assignment  gets  four; 

End  Dwell  Array  Face  Assignment; 


Figure  4.9  Dwell  Array  Face  Assignment. 

8.  Comply  With  Radar  Doctrine 

The  function  of  this  module  is  to  ensure  that  the  selected  beam's  transmission 
parameters  comply  with  the  doctrines  imposed  by  the  program  operators. 

The  common  memory  data  consumed  by  this  module  includes  the  radar 
silence  flag,  produced  by  the  Command  and  Decision  User  services  process,  and  three 
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doctrine  commands  produced  by  the  Switch  Action  and  Display  process.  The  doctrine 
commands  consumed  are: 

•.  the  radar  transmitter  power  flag, 

•.  the  radar  power  option  flag  and, 

•.  the  inhibited  radiation  regions. 

This  module  does  not  consume  any  internal  data  and  there  are  no  locally  declared  data 
structures.  [Ref.  5:  p.  84] 

This  module  does  produce  data  for  the  Output  Channel  Control  Buffer  data 
structure  of  the  Radar  Event  Control  Table. 

This  module  is  not  implemented  in  this  program.  The  algorithm  for  this 
module  is  presented  in  Figure  4.10  . 


Begin  Comply  With  Radar  Doctrine: 

If  the  radar  silence  tlag  is  false  then 

Set  the  transmitter  power  based  on  the  Haas  set 
bv  the  Switch  Action  and  Display  process:” 

If  beam's  lie  within  the  inhibited  radiation 
regions  then 

Set  transmitter  flag  to  false; 

End  if; 

Else 

Set  transmitter  flag  to  false; 

End  if  else; 

End  Comply  With  Radar  Doctrine; 


Figure  4.10  Comply  With  Radar  Doctrine  Algorithm. 

9.  Satisfy  SPY-1A  Hardware  Constraints 

The  function  of  this  module  is  to  optimize  the  available  radar  resources  for 
dwell  transmission  during  each  scheduling  interval.  The  AEGIS  Program 
Specifications  call  for  the  use  of  digital  filters  to  optimize  dwell  transmission 
parameters.  In  the  NPS  model,  a  fixed  resource  percentage  scheme  is  used  to  calculate 
the  amount  of  radar  resources  consumed.  Each  radar  event  is  assigned  a  constant 
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resource  percentage  requirement.  As  the  requested  beams  are  selected  for  scheduleding, 
their  constant  resource  requirements  are  subtracted  form  the  total  radar  resources 
available.  The  total  radar  resources  for  the  start  of  each  scheduling  interval  is  100%. 
Beams  are  no  longer  selected  once  the  available  resources  have  been  depleted,  filenum 
rsm9 


Begin  Satisfy  Hardware  Constraints: 

Ascertain  the  beams  identity  and  set 
percent  equal  to  beams  alloted  resource: 

Radar  resources  used  gets  radar  resources  plus  percent; 

If  radar  resources  used  is  less  than  100%  then 

set  dwell  resources  used  to  100%  minus  the 
radar  resources  used: 

Set  the  hardware  constraints  Hag  to  true: 

Else 

Set  radar  resources  used  to  radar  resources  used 
minus  percent: 

Set  the  hardware  constraints  Hag  to  false: 

End  if  else: 

End  Satisfy  Hardware  Constraints; 


Figure  4.11  Satisfy  Hardware  Constraints  Algorithm. 


This  module  does  not  consume  or  produce  any  common  memory  data 
structures. 

The  input  parameters  to  the  Satisfy  SPY-1A  Hardware  Constraints  procedure 
are  as  follows: 

•  id  is  a  que  type  identifier  used  to  determine  what  percentage  of  resources  are 
required.  This  parameter  is  passed  by  value. 

•  rru  is  an  input/ output  parameter  containing  the  running  total  of  radar  resources 
used  for  the  current  scheduling  interval.  The  parameter  is  passed  by  reference. 

•  dru  is  an  input/output  parameter  containing  the  total  percentage  of  radar 
resources  consumed  after  selection  of  the  current  beam. 

•  hwc  is  a  boolean  output  parameter  which  is  set  to  true  if  the  hardware 
constraints  are  satisfied.  The  parameter  is  passed  by  reference. 

The  following  data  structures  are  locally  declared: 
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•  srch  pent  is  a  constant  representing  the  percentage  of  resources  allotted  for 
each- search  dwell. 

•  sr_pcnt  is  a  constant  representing  the  percentage  of  resources  allotted  for  each 
special  request  dwell. 

•  trk_pcnt  is  a  constant  representing  the  percentage  of  resources  allotted  for  each 
tracK.  dwell. 

•  mssl_pcnt  is  a  constant  representing  the  percentage  of  resources  allotted  for 
each" missile  dwell. 

•  percent  is  a  temporary  variable  used  to  hold  the  percent  of  resources  being 
considered. 

The  algorithmic  description  for  the  Satisfy  Hardware  Constraints  procedure  is 
presented  in  Figure  -i.il  . 

10.  Place  Dwells  Into  Dwell  Buffers 

The  function  of  this  module  is  to  transmit  the  formatted  dweil  information  to 
the  two  external  dweil  butlers.  Formatting  is  complete  upon  satisfying  the  hardware 
constraints.  If  the  seiectea  oeam  satisfies  those  constraints,  then  it  is  transmitted  to  the 
external  dweil  butlers  for  radar  transmission. 


3egin  Fill  External  Dwells; 

Point  t o  the  current  Output  Control  Channel  Butler; 

Set  the  Output  Control  Channel  Buffer  data  structure  to 
the  ocb_data  structure  of  the  Radar  Event  Control  Table; 

Point  to  the  Current  R_to_0  data  structure; 

Set  the  R  to  O  data  structure  to  the  appropriate  data 
fields  in  the  Radar  Event  Control  Table; 

End  Fill  External  Dwells; 


Figure  4.12  Fill  External  Dwells. 


This  procedure  consumes  the  current  pointers  to  the  external  dwell  buffers 
which  are  passed  by  reference  in  the  following  input/output  parameters: 

•  pi  and  p2  are  pointers  to  the  Output  Control  Channel  Buffer  common  memory 
data  structure. 

•  p3  and  p4  are  pointers  to  the  R_to_0  common  memory  data  structure. 

•  pr  is  a  pointer  to  the  Output  Control  Channel  Buffer  data  contained  in  the 
internal  Radar  Event  Control  Table  data  structure  for  the  current  the  current 
selected  beam. 
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There  are  no  other  locally  declared  data  structures  in  this  module.  Figure  4.12 
gives  the  algorithmic  description  of  this  procedure. 

11.  Radar  Load  Evaluation 

The  function  of  this  module  is  to  maintain  a  running  total  of  the  amount  of 
radar  time  being  expended  in  tracking  targets.  The  total  is  reset  to  zero  each  time  the 
Load  Evaluation  process  tells  the  Radar  Scheduler  to  reset  its'  track  time  counter. 
Beam  transmission  data  is  then  sent  to  the  Load  Evaluation  process.  This  module  is 
executed  only  if  the  selected  beam  has  satisfied  the  hardware  constraints.  [Ref.  5:  p. 
87] 

The  Load  Evaluation  module  consumes  the  common  memory  interface  from 
the  load  evaluation  process  (TAB9.LIB).  The  data  structure  consumed  is  the  track  time 
counter  reset  flag.  The  common  memory  interface  information  produced  by  this 
moduie  includes  information  concerning  the  transmitter  duty  factor  for  the  current 
beam,  the  total  time  spent  on  dummy  dwells  during  the  interval,  and  the  number  of 
horizon  and  above  horizon  search  beams  that  were  not  scheduled  during  the 
interval. This  information  is  placed  in  the  common  memory  interface  of  TAB65.LIB. 
[Ref.  5:  p.  88] 

Internal  data  consumed  bv  this  module  includes  the  beams  identity  and  the 
percentage  of  resources  used  by  the  beam.  No  internal  data  is  produced  oy  this 
module.  Also,  this  module  does  not  use  any  locally  declared  data. 

The  algorithm  for  Load  Evaluation  is  given  in  Figure  4. 13  . 

12.  Elapsed  Time  This  Interval 

The  function  of  this  module  is  to  compute  the  amount  of  time  spent 
scheduling  and  formatting  the  radar  beams  during  the  interval. 

No  common  memory  interface  data  is  consumed  or  produced  by  this  module. 

The  module  does  consume  the  internal  Radar  Scheduler  data  structure 
rs_time.  Each  time  the  module  is  executed  a  new  value  for  the  elapsed  time  is 
produced. 

The  Elapsed  Time  This  Interval  module  uses  the  following  local  data 
structures: 

•  et  is  an  input/output  parameter  that  holds  the  elapsed  time. 

•  rtim  is  an  input/output  parameter  that  holds  the  Radar  Scheduler  time. 

•  oltim  is  a  variable  to  hold  the  old  time  value. 

Figure  4.14  shows  the  algorithm  used  by  the  Elapsed  Time  procedure. 
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Begin  Radar  Load  Evaluation; 

Increment  the  Duty  factor  variable  (fore  or  aft); 

Increment  the  phase  shifter  variable  (fore  or  aft); 

If  the  track  time  counter  reset  variable  is  true  then 

Set  track  time  counter  to  zero: 

If  selected  beam  is  a  track  or  missile  beam  then 

Increment  the  track  time  counter: 

If  the  selected  beam  is  a  dummy  dwell  then 

Increment  the  dummy  dwell  time  variable; 

If  the  selected  beam  is  a  search  beam  then 

decrement  the  unsked  search  beam  variable: 

End  Radar  Load  Evaluation: 


Figure  4.13  Radar  Load  Evaluation  Algorithm. 


Begin  Elapsed  Time; 

Old  time  gets  the  value  of  the  real  time; 

Real  time  gets  the  current  value  of  real  time; 

Elapsed  time  gets  elapsed  time  plus  real  time 
minus  the  old  time; 

Return  the  new  values  of  elapsed  time  and  real  time. 
End  Elapsed  Time; 


Figure  4.14  Elapsed  Time  Algorithm. 

13.  Radar  Event  Control  Table  Analysis 

This  module  is  designed  to  dump  selected  fields  from  the  Radar  Event  Priority 
List  and  the  Radar  Event  Control  Table  into  a  file  called  RSOUT.TXT.  When  the 
Radar  Scheduler  program  completes  its  execution,  the  file  will  contain  the  requested 
beams  from  the  Radar  Event  Priority  List  and  the  selected  beams  from  the  Radar 
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Event  Control  Table.  The  results  can  be  analyzed  by  comparing  the  requested  beam 
data  to  the  scheduled  beam  data. 


Begin  Radar  Scheduler  Dump; 

Traverse  the  Priority  Event  List; 

If  Priority  Event  List  status  is  true  then 

if  search  or  special  request  beam  queue  then 

Traverse  search  or  special  request  beam  queue; 
Disoiav  beam  identifier: 
increment  oeam  position  count: 

End  traverse  search  or  special  request  beam  queue; 

Else 

'"raverse  track,  or  missile  beam  queue: 

Disoiav  beam  identifier: 

Increment  beam  position  count: 

End  traverse  track  or  missile  beam  queue; 

Ena  if  else; 


Start  new  line  and  dispiav  beam  positions: 

Else 

Display  "no  requests  this  interval"; 

End  if  else; 

End  traverse  Priority  Event  List; 

Traverse  Radar  Event  Control  Table; 

Dispiav  beam  identifiers; 

Display  dwell  number; 

Display  resources; 

End  traverse  Radar  Event  Control  Table; 

End  Radar  Scheduler  Dump; 


Figure  4.15  Radar  Schedular  Dump  Algorithm. 

This  module  consumes  the  Radar  Event  Priority  List  common  memory  data 
structure.  It  does  not  produce  any  common  memory  data. 

This  module  also  consumes  the  Radar  Event  Control  Table  internal  data 
structure.  It  does  not  produce  any  internal  data. 
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The  local  variables  used  in  this  module  are  defined  below: 

•  dsh  is  a  string  constant  containing  a  dashed  line  for  formating  the  output. 

•  sptr  is  a  workina  pointer  used  in  traversing  the  Radar  Event  Prioritv  List's 
search  or  special  request  beam  queue. 

•  tptr  is  a  working  pointer  used  in  traversing  the  Radar  Event  Prioritv  List's  track 
or  missile  beanfqueue. 

•  p  is  a  working  pointer  used  in  traversing  the  Radar  Event  Control  Table. 

•  Control  Table. 

The  dump  procedure  declared  in  this  module  uses  the  pointers  described 
above.  The  procedure  aiso  detines  the  following  local  data  structures: 

•  ctr  is  used  as  an  index  for  traversing  the  Radar  Event  Priority  Event  list. 

•  start  is  a  variabie  used  to  keep  track  of  che  starting  vaiue  used  in  the  "FOR" 

loop  control  structure. 

•  an  is  a  variable  used  to  keep  track  of  che  queue  position. 

The  the  algorithm  for  this  procedure  is  presented  in  Figure  4.  15  . 

14.  Free  Rauar  Event  Control  Taiiie  Memory' 

The  function  of  this  module  is  to  return  the  Rauar  Event  Control  Table  nodes 
to  the  pooi  of  available  nodes  at  the  end  of  each  scheduling  interval  so  they  can  be 

reused.  This  is  accomplished  by  linking  the  Rauar  Event  Control  Table  to  the  End  of 

the  node  pooi.  Then  as  the  nodes  are  required,  the  Get  RECT  Node  function  from  the 
RSM5  module  returns  them  to  the  Radar  Event  Control  Table. 


Begin  Free  Memory; 

Find  the  end  of  the  RECT  node  pool; 

Insert  the  Radar  Event  Control  Table 
at  the  end  of  the  RECT  node  pool; 

Return  null  Radar  Event  Control  Table  pointer; 

End  Free  Memory'; 


Figure  4.16  Free  Memory  Algorithm. 

The  Free  Memory  module  does  not  produce  or  consume  any  common 
memory  data  structures. 
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The  module  consumes  the  internal  data  structure,  Radar  Event  Control  Table, 
and  reproduces  the  pool  List. 

The  module  produces  the  local  pointer  p  for  use  by .  the  Free  Memory 
procedure.  Figure  4.16  contains  the  algorithmic  description  of  this  procedure. 

F.  RADAR  SCHEDULER  COMMON  SERVICE  ROUTINES 

The  Common  service  routines  used  are  designed  to  be  accessible  to  all  the  major 
processes.  For  simplicity,  the  common  service  routines  used  by  the  Radar  Scheduler 
program  have  been  included  in  the  Global  module.  Some  of  the  previously  designed 
Common  Service  Routines  functions  have  been  replaced  by  standard  Ada  packages, 
such  as  the  type  conversion  and  string  manipulation  functions.  The  procedures  await, 
advance,  ticket  etc.,  are  expected  to  be  replaced  by  MCORTEX  procedures  and  appear 
only  as  stubs  in  this  program.  The  design  decisions  for  the  Common  Service  Routines 
implemented  in  this  model  are  included  here. 

1.  Random  Number  Generator 

The  Random  Number  Generator  is  a  function  that  returns  a  pseudo-random 
number.  The  function  uses  a  congruence  algorithm  to  generate  numbers  in  the  range 
from  zero  to  the  "t".  In  this  case  "t"  is  31099. 


Begin  Random  Number  Generator; 

If  this  is  the  first  call  to  this  module  then; 

set  x  equal  to  seed  number; 

Compute  the  random  number; 
set  "x"  equal  to  the  random  number; 
Return  the  value  of  "x"  to  the  caller; 

End  Random  Number  Generator; 


Figure  4.17  Random  Number  Generator  Algorithm. 

This  routine  does  not  consume  or  produce  any  common  memory  or  Radar 
Scheduler  data  structures.  The  module  does  consume  the  variable  "x"  which  is  declared 
in  the  Global  package  body  along  with  the  function.  Unlike  the  function,  the  variable 
"x"  is  hidden  from  the  users  of  the  Random  Number  Generator.  This  variable  is 


57 


initialized  by  the  Global  package  body  and  thereafter  set  to  the  pseudo-random 
number  returned  after  each  execution  of  the  function.  The  variable  "x"  is  then  used  as 
a  seed  for  each  successive  call  to  the  function. 

The  data  structures  defined  by  this  function  are: 

•  a  is  a  constant  approximately  equal  to  the  square  root  of  "t". 

•  b  is  a  constant  that  is  relatively  prime  to  "t". 

•  t  is  a  constant  which  defines  the  upper  bound  of  the  numbers  generated. 

•  y  is  a  temporary  variable  used  to  calculate  the  random  number. 

Figure  4.17  presents  the  algorithm  for  the  random  function. 

2.  Clock  Routine 

This  Common  Service  Routine  is  designed  to  simulate  a  real  time  millisecond 
clock.  Each  time  this  function  is  called  the  variable  time  is  incremented.  This  new  value 
of  lime  is  'hen  returned  to  the  calling  process. 

This  module  does  not  consume  or  produce  any  common  or  internal  data 
structures. 

The  only  data  structure  used  by  this  function  is  the  variable  time,  which  is 
declared  in  the  package  body  of  the  Global  module.  The  Clock  Algorithm  is  shown  in 
Figure  4.18  . 


Begin  Clock; 

Increment  "time"; 

Return  the  value  of  "time"; 
End  Clock; 


Figure  4.18  Clock  Algorithm. 

3.  Initialize  Radar  Event  Priority  List 

The  purpose  of  this  procedure  is  to  initialize  the  data  fields  in  the  Radar  Event 
Priority  List.  It  is  designated  as  a  Common  Service  Routine  because  it  must  be 
executed  prior  to  any  process  using  the  list. 

This  routine  does  not  consume  any  common  memory  data  structures. 
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No  Radar  Scheduler  internal  data  structures  are  produced  or  consumed  by 
this  routine. 

There  is  only  one  local  variable  declared  by  this  procedure,  the  variable  "i". 
which  is  used  as  an  index  for  traversing  the  Radar  Event  Priority  List. 

The  Initialization  algorithm  is  presented  in  Figure  4.19  . 


Begin  Initialization: 

For  "i"  gers  one  to  maximum  numoer  or' events  iooo: 

Set  initial  values  for  the  common  data  fields: 

Assign  ailowed  execution  periods  based  on 
the  index  "i"  and  the  description  given  in 
Taoie  &prilst; 

Assign  beam  queue  tvpes  maximum  nodes  based  on 
die  index  and  the  description  given  in 
~aoie  Sipnist: 

Set  the  iink  to  the  next  event  in  the  list: 

End  loop: 

Reset  last  link  to  zero: 

Assign  event  names  naccordanee  with  Taoie  ekpriist: 
End  initialization: 


Figure  4.19  Priority  Event  List  Initialization  Algorithm. 
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V.  TEST  PLAN 


The  testing  requirements  for  the  NPS  model  of  the  Radar  Scheduler  process  have 
a  limited  set  of  goals.  The  primary  goal  is  to  test  for  logical  correctness  and  secondarily 
to  test  the  performance  of  the  code  generated  by  JANUS/ ADA's  compiler. 

Testing  for  logical  correctness  entails  verifying  that  the  program  conforms  to  its 
specifications,  implements  the  design  algorithm,  and  produces  the  required  output. 
Testing  of  the  Radar  Scheduler  process  for  this  thesis  was  done  primarily  by  a  "bottom 
up",  "white  box'  approach.  The  reason  for  taking  this  approach  as  opposed  to  a  top 
down  approach  is  that  the  basic  design  had  already  been  implemented  once  in  the 
PL,  I-SO  version  of  the  code.  Since  this  was  the  case,  it  was  feit  that  'he  overall  design 
was  sound  and  there  was  very  iittie  risk  in  implementing  and  resting  the  modules  from 
the  bottom  an.  Furthermore,  this  ailoweu  for  more  extensive  testing,  as  there  was  iittie 
need  for  moduie  stuns. 

A  test  harness  was  designed  for  each  moduie  with  an  eifort  towards  exercising,  as 
much  as  possible,  each  branch  of  the  code  for  correct  execution  and  robustness.  The 
suooruinate  modules  were  tested  first.  The  test  harnesses  were  then  expanded  to 

incorporate  the  modules  at  the  next  higher  level.  At  each  phase  of  the  testing  the  test 
harnesses  were  modified  to  allow  the  input  of  relevant  data  to  exercise  the  branches  of 
the  code  and  then  record  the  results  for  examination.  In  some  cases  print  statements 
were  inserted  into  the  code  to  ensure  that  a  particular  branch  was  being  executed 
properly. 

A.  DESIGN  AND  DOCUMENTATION  OF  TEST  MODULES 

1.  Search  Management  Test  Harness 

The  Search  Management  test  harness  is  made  up  of  two  modules,  the  Search 
Management  Initialization  module  and  the  Fill  Search  Queue  module.  Collectively 
these  two  modules  provide  the  search  and  special  request  beams  for  the  Radar 
Scheduler  Process. 

The  Search  Management  Initialization  module  is  executed  once.  Its'  purpose 
is  to  allocate  memory  for  search  nodes  (TAB  1. LIB),  and  create  empty  request  queues 
for  each  search  and  special  request  event  in  the  Radar  Event  Priority  List  (TABO.LIB). 
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The  Fill  Search  Queue  module  is  responsible  for  filling  the  search  and  special 
request  queues  with  the  proper  beam  data.  The  data  supplied  by  this  module  includes 
the  beam  mode,  a  unique  beam  identifier,  beam  position,  instrumented  range,  blanking 
gates,  end  of  frame  indicator,  and  a  requestor  identity.  This  design  version  imposes  a 
static  set  of  beam  requests,  for  test  purposes.  Whenever  the  module  is  executed,  the 
same  set  of  beam  requests  are  placed  in  the  queues.  The  static  set  of  beam  requests  are 
used  to  facilitate  the  data  analysis  of  the  Radar  Scheduler  and  is  not  meant  to 
accurately  model  the  Search  Management  process.  The  source  code  for  the  Search 
Management  modules  is  contained  in  Appendix  D. 

2.  Track  Management  Test  Harness 

The  Track  Management  test  harness  is  composed  of  the  Track  Management 
module  (TRCM)  and  a  Track  Management  Initialization  module  (TMM1).  The 
Initialization  module  is  designed  co  allocate  memory  for  track  nodes  (TAB2.LIB)  and 
create  empty  request  queues  for  each  track  and  missile  event  in  the  Radar  Event 
Priority  List  (TABO.LIB) 

The  main  Track  Management  module  is  used  to  search  through  the  Track  Fiie 
correlating  track  modes  to  radar  track  event  modes.  When  a  correlation  is  found,  the 
track  is  added  to  the  Priority  Event  List's  request  queue.  This  moduie  does  not 
accurately  model  the  Track  Management  process  and  again  is  used  only  for  testing  the 
Radar  Scheduler  Source  code.  The  source  code  for  these  modules  is  located  in 
Appendix  D. 

3.  Detection  Processing  Initialization  Module 

The  Detection  Processing  Initialization  module  (DPM)  creates  the  Track  File 
and  initializes  its  data  fields  with  viable  data  for  testing  the  Radar  Scheduler.  The 
number  of  Track  File  nodes  initialized  is  determined  by  the  test  harness  operator  at  run 
time,  when  he  is  directed  to  provide  the  "number  of  tracks"  to  be  initialized. 
Calculation  of  the  data  field  values  in  the  track  node  are  based  on  the  values  returned 
by  the  pseudo-random  number  generator.  Therefore  successive  runs  of  the  test  harness 
with  identical  input  from  the  operator  will  generate  the  same  Track  File  data  each 
time.  The  source  code  for  this  module  is  located  in  Appendix  D. 

4.  Operator  Interface  Module 

The  Operator  Interface  module  provides  the  user  of  the  test  harness  the  ability 
to  alter  the  number  of  tracks  to  be  initialized,  the  desired  number  of  intervals  to  be 
run,  and  how  often  the  results  are  to  be  displayed.  Actually  the  results  are  sent  to  a  file 
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that  can  be  examined  by  the  user  after  the  test  run.  A  short  messages  is  printed  to  the 
screen  whenever  results  of  the  scheduling  interval  are  sent  to  the  file.  This  can  also  be 
used  to.  time  the  scheduling  interval  loop  without  the  overhead  of  the  routines  that  are 
only  executed  once  to  initialize  the  data  structures. 

The  operator  is  cautioned  that  using  a  very  large  number  for  the  number  of 
intervals  and  a  small  interval  display  delay  period  will  generate  a  very  large  file  of  test 
results  and  may  cause  a  heap  or  stack  overflow.  If  the  operator  desires  such  a  run, 
then  the  print  functions  in  RSM13.PKG  can  be  easily  modified  to  print  to  the  screen, 
by  eliminating  the  word  "Text"  from  the  print  commands. 

B.  DATA  ANALYSIS  METHODS 

The  Radar  Scheduler  model  was  designed  so  that  the  results  of  any  particular 
scheduling  interval  may  be  recorded  in  the  file  RSOUT.TXT.  For  each  scheduling 
interval  being  'ecordea,  the  output  file  holds  a  section  of  information  on  the  requested 
beams  from  the  Radar  Event  Priority  List  and  a  section  of  information  on  dwells 
scheduled  from  the  Radar  Event  Controi  Taoie. 

The  requested  beam  section  shows  the  scheduling  interval  number  and  lists  the 
events  in  their  current  priority  order.  Aiong  with  each  event  is  a  list  of  the  requested 
beams  if  any,  and  ’heir  position  in  the  request  queue.  All  the  beams  are  identified  by  a 
unique  beam  identifier. 

The  scheduled  dwell  section  shows  the  interval  number  the  dwells  were  scheduled 
in  and  a  list  of  all  dwells  scheduled.  For  each  dwell  the  following  is  provided: 

•.  the  unique  beam  identity  of  the  dwell, 

•.  the  percentage  of  resources  left  after  formatting  the  selected  beam  into  a  dwell, 
and 

•.  the  dwell  index  number  of  the  selected  beam. 

The  Radar  Scheduler's  output  is  analyzed  by  comparing  the  requested  beam 
identities  to  the  selected  beam  identites  of  the  scheduled  dwells.  The  results  recorded 
over  several  intervals  indicate  how  well  the  model  is  optimizing  the  radar  resources  and 
if  the  radar  events  are  being  scheduled  efficiently. 

C.  TIMING  ANALYSIS 

To  test  the  timing  of  Radar  Scheduler  program,  a  short  message  is  sent  to  the 
screen  each  interval  display  delay  period.  When  the  first  message  is  displayed,  the 
Radar  Scheduler  has  completed  its  initialization  of  data  structures  and  completed  the 
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number  of  scheduling  intervals  equal  to  the  display  delay  period.  In  order  to  avoid  the 
initialization  overhead  at  the  start  of  the  program,  timing  must  start  when  the  first 
message  appears  and  not  when  the  program  is  first  executed.  Then  the  operator  may 
end  timing  on  any  later  interval  display  delay  period.  This  way  the  operator  can  get  a 
good  approximation  of  the  time  it  takes  to  complete  one  scheduling  interval. 

In  order  to  calculate  the  average  scheduling  interval  time,  the  overhead  from  the 
terminal  display  and  writing  to  output  file  must  be  accounted  for.  To  account  for  this, 
the  assumption  is  made  that  the  time  to  print  to  the  screen  and  dump  the  results  to  the 
output  file  is  approximately  equal  each  time  it  occurs.  In  other  words,  the  interval 
display  procedure  takes  approximately  the  same  amount  of  time  each  time  t  is 
executed. 

Let  "Tr"  equal  the  total  time  recorded  for  the  test  run.  Let  "Td"  equal  the  time  it 
takes  for  one  execution  of  the  display  procedure.  Let  "Ti"  equai  the  execution  time  for 
one  scheduling  interval.  To  calculate  "Ti"  the  following  test  procedure  was  used: 

•».  Three  runs  of  the  Raaar  Scheduler  were  maue  usinu  the  same  input.  The  results 

were  recorded  and  their  average  was  used  as  Tr". 

a.  The  interval  display  deiay  period  was  set  on  500. 

b.  The  number  of  intervals  was  set  to  1000. 

c.  Timing  was  started  on  the  first  interval  display  deiay  period.  500. 

d.  Timing  was  stopped  on  the  last  interval  display  delay  period,  1000,  which 
causecT  only  the  last  display  to  be  included  in  the  total' time  recorded. 

•.  Three  runs  of  the  Radar  Scheduler  were  taken  again  using  a  new  interval 

displav  delay  period.  The  the  run  times  were  recorded  and  again  the  average 

w’as  used  as  "Tr". 

a.  The  interval  display  delay  period  was  set  on  100. 

b.  The  number  of  intervals  was  set  to  1000. 

c.  Timing  was  started  on  the  fifth  interval  display  delay  period,  500. 

d.  Timing  was  stopped  on  the  last  interval  display  delay  period,  1000,  which 
caused-  five  display  times  to  be  included  in  the  total  time  recorded. 

For  the  first  set  of  runs  the  following  equation  holds: 

Trl  =  500Ti  +  Td. 

The  second  set  of  runs  uses  the  formula: 

Tr2  =  500Ti  +  5Td. 

Solving  the  two  simultaneous  equations  for  Ti  yields: 

Ti  =  (5Trl-Tr2)/2000. 
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Test  runs  were  made  of  the  code  generated  by  JANUS/ADA  compiler  with  all 
the  standard  pragmas,  and  then  again  on  the  code  generated  when  the  pragmas  were 
turned  off.  The  pragmas  that  were  turned  on  and  off  during  compilation  are  shown  at 
the  beginning  of  each  source  code  module.  For  consistancy,  all  the  modules  include  the 
same  pragma  statements.  The  pragmas  that  were  turned  on  and  off  are:  arithcheck. 
rangecheck,  debug,  and  enumtab. 

The  arithmetic  check  pragma  controls  the  generation  of  arithmetic  overflow 
checks.  Code  is  generated  during  compilation  to  check  all  mathematical  expressions 
when  this  pragma  is  turned  on.  [Ref.  6:  p.  B-lj 

The  range  check  pragma  controls  the  generation  of  range  checks  for  subrange 
variables  and  array  subscripts.  The  range  checK.  code  is  generated  at  compile  time  when 
the  pragma  is  turned  on.  [Ref.  6:  p.  B-2] 

The  debug  pragma  controls  the  generation  of  line  number  and  procedure  names. 
This  information  is  used  by  the  walkback  which  is  generated  after  a  run-time  error.  The 
code  generated  when  this  pragma  is  on  would  only  affect  performance  when  a  run-time 
error  occurs.  [Ref.  6:  p.  3-1] 

The  enumeration  table  pragma  controls  the  generation  of  enumeration  tables. 
These  tables  are  only  necessary  when  the  programer  is  doing  1,0  with  enumeration 
types.  The  generation  of  these  tables  at  compile  time  does  not  affect  performance,  but 
it  does  use  a  lot  of  storage  space.  [Ref.  6:  p.  B-l] 

Since  the  above  pragmas  are  turned  on  by  default,  they  have  been  explicitly 
turned  of  in  the  code.  They  can  be  turned  back  on  at  compile  time  by  the  conditional 
compilation  feature.  When  this  feature  is  off,  as  it  is  by  default,  the  lines  preceded  by  a 
are  treated  as  comments.  If  the  conditional  compilation  is  turned  on  with  the  "c" 
command  at  compile  time,  then  the  lines  preceded  by  the  symbol  are  compiled. 
[Ref.  6:  p.  B-l] 

The  first  executable  code  was  generated  with  the  pragmas  on  and  the  second  was 
generated  with  the  pragmas  off.  The  test  results  are  shown  in  Table  4  . 

Run-time  test  results  of  the  code  produced  by  the  JANUS/ADA  compiler  showed 
almost  a  two  to  one  increase  in  speed  when  it  was  recompiled  with  the  arithmetic  and 
range  checking  features  turned  off.  This  shows  that  although  there  was  a  significant 
increase  in  speed,  it  was  not  without  sacrificing  some  of  features  that  the  Ada  language 
includes.  Even  with  the  pragmas  turned  off,  the  best  speed  of  213.4  milliseconds  is  still 
ten  times  the  median  scheduling  interval  time  of  21  milliseconds  required. 
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TABLE  4 

PERFORMANCE  RESULTS 


PRAGMAS  ON 


NUMBER  OF  TRACKS:  .  50 

NUMBER  OF  INTERVALS:  .  1000 

INTERVAL  DISPLAY  DELAY:  .  500 

NUMBER  OF  INTERVALS  TIMED:  .  500 

AVERAGE  RUN  TIME  Trl:  .  223.  58  sec 

NUMBER  OF  TRACKS:  .  50 

NUMBER  OF  INTERVALS:  .  1000 

INTERVAL  DISPLAY  DELAY:  .  100 

AVERAGE  RUN  TIME  Tr2:  .  231.48  sec 

TIME  PER  SCHEDULING  INTERVAL  "Ti":  ...  0.4557  sec/int 

SCHEDULING  RATE:  .  2.2  int/sec 


PRAGMAS  OFF 


NUMBER  OF  TRACKS:  . 

NUMBER  OF  INTERVALS:  . 

INTERVAL  DISPLAY  DELAY:  .  . 
NUMBER  OF  INTERVALS  TIMED: 
AVERAGE  RUN  TIME  Trl: 

NUMBER  OF  TRACKS:  . 

NUMBER  CF  INTERVALS:  . 

INTERVAL  DISPLAY  DELAY:  .  . 
AVERAGE  RUN  TIME  Tr2: 


50 

1000 

500 

500 

107. 49 
50 

1000 

100 

110. 65 


sec 


sec 


TIME  PER  SCHEDULING  INTERVAL  "Ti":  ...  0.2134  sec/int 

SCHEDULING  RATE:  .  4.6  int/sec 


The  tests  were  run  on  the  Z-  100's  8-Bit  microprocessor.  The  target  processor  is 
the  iSBC  86/12A  Single  Board  Computer  with  a  16-Bit  microprocessor,  which  will 
increase  the  performance.  However,  it  is  doubtfull  that  this  will  be  enough  to  over 
come  a  factor  of  ten. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


This  thesis  has  developed  a  JANUS/ ADA  model  of  the  Radar  Scheduler  process. 
The  model  is  a  first  effort  in  implementing  one  of  the  AEGIS  AN’/SPY-1A  Radar 
Control  Group  modules  in  JANUS/ADA  and  as  such  it  is  a  part  of  the  continuing 
research  effort  at  the  Naval  Postgraduate  School  to  test  the  feasibility  of  replacing  the 
AEGIS  main  frame  computer  suit  with  a  multi-microprocessor  system.  Additionally, 
the  Radar  Scheduler  provides  an  example  for  studying  the  performance  of  time  critical 
programs  written  in  ADA. 

The  design  of  the  Radar  Scheduler  model  incorporates  14  modules.  The  modules 
were  designed  to  be  integrated  into  the  overall  model  with  a  minium  of  changes 
required.  In  support  of  this.  Chapter  IV.  serves  as  the  Radar  Scheduler  Design 
Document  to  be  used  as  a  reference  for  the  future  implementation  and  integration  of 
the  Radar  Scheduler  Process  with  the  remaining  Radar  Control  Group  modules.  As 
such,  any  changes  to  the  Radar  Scheduler's  design  should  be  reflected  in  the  design 
document. 

Logical  testing  of  the  individual  modules  was  increasingly  more  dificult  as  they 
were  integrated  into  the  main  program.  There  were  several  reasons  for  this.  First,  the 
number  of  logical  paths  to  be  examined  grew  very  rapidly  as  the  modules  were 
integrated.  In  some  cases,  the  lower  modules  had  tested  satisfactorily,  isolated  in  their 
own  test  harness.  Then  later,  while  acting  in  conjunction  with  the  higher  level  modules, 
they  developed  problems  which  were  not  accounted  for  by  the  test  harness.  For 
example,  the  dynamic  allocation  of  local  access  data  structures,  and  some  recursively 
designed  procedures,  functioned  well  until  they  were  stressed  by  the  load  of  the  Radar 
Scheduler  test  harness.  Under  this  stress,  stack  overflow  became  a  problem.  Declaring 
the  access  types  outside  the  procedures  in  the  package  body,  and  making  the  recursive 
procedures  iterative,  solved  the  problem. 

Determining  what  the  best  testing  criteria  is,  and  formulating  a  testing  strategy  is 
difficult  without  a  more  rigorously  defined  specification.  The  logical  correctness  of  the 
module  can  not  be  determined  from  statements  such  as  "in  a  timely  manner". 
However,  the  Radar  Scheduler  output  indicates  that  the  requested  beams  are  being 
scheduled  in  a  priority  order,  and  that  those  beams  that  are  not  scheduled  during  the 
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interval  are  being  reprioritized  and  scheduled  in  later  intervals.  The  radar  resources 
remaining  at  the  end  of  the  interval  indicate  that  the  resources  are  being  consumed 
until  there  is  no  longer  enough  to  fill  the  remaining  requests  for  that  interval. 

Two  conclusion  are  evident  from  the  preliminary  real-time  testing.  First,  the  code 
generated  with  the  range  and  arithmetic  checking  turned  off  executes  at  twice  the  speed 
of  the  code  normally  generated  by  the  compiler.  Second,  the  best  run-time  was  ten 
times  slower  than  the  median  scheduling  interval  time  required.  In  view  of  this,  further 
testing  should  be  done  to  isolate  the  cause.  The  most  time  intensive  portions  of  the 
program  should  be  analyzed  first.  Identification  should  be  made  by  measuring  the 
execution  time  for  the  most  likeiv  modules  and  weighting  the  results  by  the  number  of 
times  the  module  is  executed  by  the  Radar  Scheduler  process.  Once  the  modules  have 
been  identified,  the  actual  cause  of  the  time  deiav  can  be  asessed.  The  algorithms  and 
data  structures  can  be  examined  for  improvement.  This  vav.  a  more  accurate 
accounting  of  the  module  design,  and  the  feasibility  of  reai-ume  programming  in  ADA 
can  be  made. 

The  supplementary  processes  (TRCM.  SRCM.  DRCM.  and  ARCM)  were 
developed  as  test  harnesses  to  supply  the  Radar  Scheduler  with  radar  event  requests. 
These  processes  will  be  fully  implemented  i.n  the  Janus/ Ada  programming  language  as 
the  NPS  AEGIS  Project  progresses.  Ultimately  the  processes  will  be  integrated  into  a 

multi-microprocessor  model  of  the  Radar  Controller. 

To  completely  model  the  Radar  Controller,  several  major  tasks  remain.  First  the 
JANUS/ADA  language  interface  to  the  MCORTEX  system  must  be  completed,  so 
that  the  Radar  Scheduler  model  can  be  run  and  tested  in  a  true  concurrent  multi¬ 
microprocessor  environment.  The  information  gained  from  this  will  be  valuable  to  the 
future  programmers  of  the  remaining  processes.  Next  the  Track  Processing  portion  of 
the  Radar  Control  Group  should  be  implemented.  This  portion  is  expected  to  be 
numerically  intensive  and  should  provide  a  good  basis  for  testing  the  performance  of 
the  code  produced  by  the  JANUS/ADA  compiler  and  the  interaction  of  processes  on 
seperate  processors. 

When  the  remainder  of  the  processes  have  been  completed,  the  Radar  Controller 
model  can  be  evaluated  as  a  whole.  At  that  time  actual  efficiency  measurements  can  be 
made  of  the  Radar  Controller  model  and  the  effects  of  the  Ada  programming  language 
in  a  real-time  multiprocessor  programming  environment  can  be  asessed. 
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APPENDIX  A 

COMMON  MEMORY  INTERFACE  SOURCE  CODE 


--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  3  Dec  86 
--  MODULE  TYPE:  External  data  structure 

—  PURPOSE:  Common  memory  interface  to:  Radar  Scheduler,  Search  Management, 
--  and  Track  Management  processes 

--  NAME:  Priority  Event  list  ...  TABC.LI3 

--  This  data  structure  is  the  list  of  radar  events  in  priority  order. 

—  Each  element  m  the  list  holds  information  on  the  event  cueue  it 
--  points  to. 

pragma  arithcheck(off) ;  pragma  debug(off ) ; 
pragma  enumtab(off ) ;  pragma  range check (off) ; 

@  pragma  arithcheck(on) ;  pragma  debucj(on) ; 

®  pragma  enumtao (on ) ;  pragma  rangecheck(on) ; 

WITH  taol,tab2; 

PACKAGc,  "aoO  , « 

lo_enhnc:  CONSTANT  INTEGER :=  4: 
max_ori:  CONSTANT  INTEGER :=  35; 

TYPE  QueType  IS  (search, special_reauest , track, missile) ; 

USE  tabl,tab2; 

TYPE  3eamOue  IS  RECORD 
CASE  kind:  QueType  IS 

WHEN  search  f  special_request  => 

Snode :  SearchPtr;  --  see  TAB1.LIB 

WHEN  track  |  missile  => 

Tnode :  TrkPtr,*  --  see  TAB2.LIB 

WHEN  others  => 
null; 

END  CASE; 

END  RECORD; 

TYPE  pri_lst_info  IS  RECORD 
Status  :  BOOLEAN; 
eventnm  :string(40); 
max_nodes : INTEGER; 
que_id  :  QueType; 
que_ptr  :BeamQue; 
enhnc  : BOOLEAN; 
b_pri  : INTEGER; 

C_pri  : INTEGER; 
ltx  :  INTEGER; 

allwd  ltx : INTEGER; 
slct_Ilg  : BOOLEAN; 

nxt  : INTEGER;  --  pointer  to  next  priority  in  list 

END  RECORD; 

TYPE  PriLstPtr  IS  ACCESS  pri_lst_info; 

TYPE  PriLstArray  IS  ARRAY(1 . ,max_pri)  OF  PriLstPtr; 
pri_lst  :  PriLstArray; 

END  tabO; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  3  Dec  86 
--  MODULE  TYPE:  External  data  structure 

--  PURPOSE:  Common  memory  interface  to:  Radar  Scheduler,  Search  Management, 
--  and  Track  Management  processes 
--  NAME:  Priority  Event  List  ...  TABO.PKG 

pragma  arithcheck(of f ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangecheck(of f ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  BODY  tabO  IS 

i : INTEGER; 

BEGIN 

FOR  i  IN  !..max_pri  LOOP 

pri_lst(i):=  NEW  pri_list_info; 

END  LOOP; 

END  tabO; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  Common  memory  interface 
--  NAME:  Search  Node .. .TAB1 .LIB 

--  This  interface  is  a  search  beam  node.  It  acts  as  a  template  for  the 
—  nodes  which  make  up  the  horizon  search,  above  horizon  search  and 
--  special  request  queues. 

--  The  Search  Management  Process  fills  the  queue  and  the  radar  Scheduler 
--  Process  empties  it. 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 

pragma  enumtab(off ) ;  pragma  ranaecheck(off ) ; 

@  p'ragma  arithcheck(on) ;  pragma  debug'(on); 

@  pragma  enumtab(on;;  pragma  rangecheck(on) ; 

PACKAGE  tabl  IS 

TYPE  BeamPosition  IS  RECORD 
azim  :  INTEGER; 
elev  :  INTEGER; 

END  RECORD; 

TYPE  SrchData  IS  RECORD 
mode  :  "INTEGER; 

bid  :  string(3); 

beam_posil  :  BeamPosition; 
inst^rce  :  INTEGER; 

stc_"iata  :  INTEGER; 

doct_blnk_gte :  INTEGER; 
cltr_olnk_gte INTEGER; 
eof_~ncic  ” :  BOOLEAN; 

req_id  :  INTEGER; 

END  RECORD; 

TYPE  SrchDatPtr  IS  ACCESS  SrchData; 

TYPE  SearchNode; 

TYPE  SearchPtr  IS  ACCESS  SearchNode; 

TYPE  SearchNode  IS  RECORD 
info:  SrchDatPtr; 
nxt  :  SearchPtr; 

END  RECORD; 

srch_node:  SearchPtr; 

END  tabl; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  24  Jun  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  common  memory  interface 
--  NAME:  Track  Node  ...  TAB2.LIB 

--  This  data  structure  is  a  track  request  beam  node.  It  acts  as  an  overlay 
--  for  the  track  request  queues  resident  in  the  Priority  List.  The  Track 
--  Management  Process  fills  the  queues  with  requests  for  track  beams  and 
--  the  Radar  Scheduler  Process  empties  them  as  the  track  beams  are  scheduled. 

pragma  arithcheck^off ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangechecK(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug'(on)  • 
i§  pragma  enumtab(on);  pragma  rangecneck(on)  ; 

WITH  tab7 ; 

PACKAGE  tab 2  IS 

USE  tab7 ; 

TYPE  Trklnfo  IS  RECORD 
mode  :  INTEGER : 

bid  :  scrmaiS); 

o_irk:  PtrTrkFile;  --  See  IAB7.LI3 
END  RECORD ; 

TYPE  TrackNode; 

TYPE  TrkPtr  IS  ACCESS  TrackNode; 

TYPE  TrackNode  IS  RECORD 
info  :  TrKinfo; 
nxt  :  TrkPtr,- 
END  RECORD; 

trk_node :  TrkPtr ; 

END  tab2; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  24  Jun  86 
--  MODULE  TYPE:  external  table 
—  PURPOSE:  common  memory  interface 
--  NAME:  I_to_R  ...  TAB3*. LIB 

--  This  table  is  an  interface  data  structure  which  communicates  SPY-1  radar 
--  status  to  the  Radar  Scheduling  Process. 

pragma  arithcheck(of f ) ;  pragma  debug(off'); 
pragma  enumtab(off ) ;  pragma  rangechecx(of f ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  tab3  IS 

TYPE  SPY1 .status  IS  RECORD 
resyncn_time  .  INTEGER; 
loop_con  :  INTEGER: 

xmsh_scatus  :  BOOLEAN; 

END  RECORD; 

TYPE  StatPtr  IS  ACCESS  SPYl_status; 

I_to_R:  StacPtr; 

END  taDS  ; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  24  Jun  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  common  memory  interface 
--  NAME:  A_to_R  . ..TAB4.LIB 

--  This  interface  data  structure  communicates  RCS  commands  to  the  Radar 
--  Scheduler  to  aid  in  the  formating  of  the  radar  dwell  buffer. 

pragma  arithcheckfof f ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  tab4  IS 

TYPE  InhibicReaion  IS  RECORD 
start  bng  : INTEGER; 
stop_Eng  : INTEGER; 

END  RECORD; 

TYPE  OpDoct  IS  RECORD 
mtrks  .-INTEGER; 

mmcvls  :  INTEGER; 
dDlV_rect  : INTEGER; 

END  RECORD; 

TYPE  RCS  command  IS  RECORD 
?wr_rlg  BOOLEAN ; 

rad_pwr_oDcion :  BOOLEAN; 

rad^inhibc_regions :  array U • -5)  OF  InnibitRegion ; 

OD_COCC  :  QODOCC; 

END  RECORD; 

TYPE  ?tr_A_to_R  IS  ACCESS  RCS_command; 

A_to_R  :  Ptr_A_to_R; 

END  tab4; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  22  Oct  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  common  memory  interface 
--  NAME:  A_to_R  . . . TAB4.PKG 

--  This  interface  data  structure  communicates  RCS  commands  to  the  Radar 
--  Scheduler  to  aid  in  the  formating  of  the  radar  dwell  buffer. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off) ;  pragma  rangechecfc(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  BODY  tab4  IS 

BEGIN 

A_to_R:=  NEW  RCS_command; 

END  tab4; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 
--  PURPOSE:  Common  Memory  Interface 
--  NAME:  C_to_R  ...  TAB5.LIB 

--  This  table  is  an  interface  between  the  C&D  User  Services  Process 
--  and  the  Radar  Scheduling  Process. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  tab5  IS 

rdr_silnce:  300LEAN; 

END  tab5 ; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 
—  PURPOSE:  Common  Memory  Interface 
--  NAME:  B_to_R  ...  TA86.LI3 

--  This  interface  data  structure  communicates  information  concerning 
--  array  face  limits  and  ships  motion  matrix  to  the  Radar  Scheduler 
--  Process.  The  information  is  developed  in  the  Beam  Stabilization 
--  Process. 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 

pragma  enumtab(ofr ) ;  pragma  rangecheck(off ) ; 

(§  pragma  arithcheckt  on) ;  pragma  debug(,on); 

0  pragma  enumtab(on) ;  bragma  rangecheck(on ; 

PACKAGE  labb  :S 

TYPE  L_R_Limits  IS  RECORD 
limic_ieft:  INTEGER; 
naht_limit:  INTEGER; 

END  RECORD; 

TYPE  F aceLimits  IS  ARRAY ( 1 . .4)  OF  L_R_Limits; 

TYPE  NomonMacnx  IS  RECORD 
;:_sniD_dot;  INTEGER; 
y_ship_don:  INTEGER; 
rooi  ;  INTEGER; 

31  ter.  ;  INTEGER; 

vaw  :  INTEGER ; 

END  RECORD ; 

TYPE  3_R_Incerfac2 ; 

TYPE  BtoR  IS  ACCESS  3  R  Interface; 

TYPE  3_A_Intarface  IS  RECORD 

facejantenna_iimi cs :  FaceLimics ; 
ships  motion  matrix:  MotionMatrix; 
azim_Iimit_sTope  :  INTEGER; 

END  RECORD; 

B_tO_R :  BtoR; 

END  tab6; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  22  Oct  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  common  memory  interface 
--  NAME:  Track  File  . ..TAB7.LIB 


--  This  external  table  is  the  radar  control  system  track  file.  The  data 
—  structure  is  a  linked  list  based  on  a  pointer  which  is  passed  between 
--  processes  which  require  access  to  the  track  file  for  data  on  tracks. 

pragma  arithcheckfoff ) ;  pragma  debug(off); 
pragma  enumtab(off) ;  pragma  rangechecx(of f ) ? 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 


WITH  Longops ; 

PACKAGE  cab 7  IS 

USE  Longops ; 

TYPE  Position 
x 

y 

slnt_rnge 
::_do  c 
y_do  c 
z_dot 
rge_dot 
END  RECORD; 


IS  RECORD 
INTEGER? 
INTEGER ; 
INTEGER; 
Lona_Inceger  ? 
INTEGER ? 
INTEGER  ? 
INTEGER ; 
INTEGER ; 


Long_Integer  from  Longops  package. 


TYPE  TimAlwdDwl  13  RECORD 
msw  :  INTEGER ; 

Isw  :  INTEGER; 

END  RECORD; 

TYPE  UpdtPosit  IS  RECORD 

msw_rate_f ilter  :  INTEGER; 
lsw_rate_f ilter  :  INTEGER; 

END  RECORD; 

TYPE  PredTimLst  IS  RECORD 
msw_azim_elev  :  INTEGER; 
lsw_azim_elev  :  INTEGER; 

END  RECORD? 


TYPE  DetectRnge  IS  RECORD 
msw  :  INTEGER; 
lsw  :  INTEGER; 

END  RECORD; 

TYPE  TimDetect  IS  RECORD 
msw  :  INTEGER; 
lsw  :  INTEGER; 

END  RECORD; 


TYPE  TrkData  IS  RECORD 


mode 
bid 

priority 

posit 

trk_xsitn_f lag 
ctl  grp_trk_num 
ctsl 

xgte_bin_num 
pred_azim 
low_elev  trk_flg 
log_ampl3_est 


INTEGER; 

string(3) ; 

INTEGER; 

Position? 

BOOLEAN? 

INTEGER; 

INTEGER; 

INTEGER; 

INTEGER? 

BOOLEAN; 

INTEGER; 


77 


xmit_reqflg  :  BOOLEAN; 

sim_tgt_Ilg  :  BOOLEAN; 

END  RECORD; 

TYPE  TrkDatPtr  IS  ACCESS  TrkData; 


TYPE  TgtData  IS  RECORD 

tim_alwd_dwl  :  TimAlwdDwl; 
mfar_^trk_num 
wcs_Tdx 
updt_tim_posit 
pred  tinO-st 
dwl_btwn_tim 
nxt  trk  xcte  bin 


INTEGER ; 
INTEGER; 
UpdtPosit; 
PredTimLst; 
INTEGER; 
INTEGER; 


prev_trx_xgte_bin:  INTEGER; 
artsc_noise_fraq:  INTEGER; 
least^oise^frad:  INTEGER; 
valia_daca_"tlg  BOOLEAN; 
lost_trk_count  :  INTEGER; 
nxt_tim_i:bl_entry :  INTEGER; 


--he=l ,me=2 , le=3 ;ale=4 ;mti=5 ; pass v=6 , miss ile=7 , cvr_plse 
trk_mode  :  INTEGER; 


rcvr_stacus_iflg  :  BOOLEAN; 
typi_passv_rlg’  :  BOOLEAN; 
v/p2lpas5V_ilg  :  BOOLEAN; 
drp_crk_flg  *  :  BOOLEAN; 

--air=l , surrace=2 , clutcer=3 
crx_class  :  -NTcGER; 


— hostiie=l ,  fnendlv=2  ,  unknown=3 
frk_id  :  INTEGER; 


vcs  fig  :  BOOLEAN; 

smtH_ampla_count ;  INTEGER; 
rnge_accel_f lg  :  BOOLEAN; 

detect_rnge  :  DetectRnge; 

tim_detect  :  TimDetect; 

caus_lost_data_pt :  INTEGER;  --unknown  pointer  type? 
END  RECORD; 

TYPE  TrkFile; 

TYPE  PtrTrkFile  IS  ACCESS  TrkFile; 

TYPE  TrkFile  IS  RECORD 

beam  data  t  TrkDatPtr; 
tgt_3ata  :  TgtData; 
nxt_trk  :  PtrTrkFile; 

END  RECORD; 

ptrk;  PtrTrkFile; 
trk_file:  PtrTrkFile; 

END  tab7 ; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  17  Nov  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  common  memory  interface 
--  NAME:  Track  File  . ..TAB7.PKG 

--  This  external  table  is  the  radar  control  system  track  file.  The  data 
--  structure  is  a  linked  list  based  on  a  pointer  which  is  Dassed  between 
--  processes  which  require  access  to  the  track  file  for  data  on  tracks. 

pragma  arithcheck(off) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug'(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  BODY  tab?  15 

BEGIN 

pcrx:=  MEW  TrxFila; 
pcrk.beam_data :=  NEW  TrkData; 
crk_file:=  NEW  TrkFiie; 
trk_file. beam  data :=  NEW  TrkData; 
pcni:-  crx_:ile; 

pr.ric.beam_aaca cri:_file .bsam_daca ; 

END  cod?  : 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 
--  PURPOSE:  Common  Memory  Interface 
—  NAME:  F_to_R  ...  TAB8.LIB 

--  This  interface  data  structure  contains  the  frequency  and  waveform 
--  information  required  by  the  Radar  Scheduler  Process  to  complete 
--  formatting  of  selected  radar  dwells. 

pragma  arithcheck(of f ) ;  pragma  debug(off); 

pragma  enumtab(off ) ;  pragma  rangechecx(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtaD( on) ;  pragma  rangecheck(on) ; 

PACKAGE  cab 8  IS 

max_dwells:  CONSTANT  INTEGER :=  10;  --  n on  previously  defined,  10  ? 

TYPE  mtiRec  IS  RECORD 
pri  :  INTEGER; 

dwl_Length:  INTEGER: 

END  RECORD:' 

TYPE  msleRec  IS  RECORD 
uplnk_freq*.  INTEGER; 
dwn  fraa  :  INTEGER: 

END  RECORD ; ‘ 

TYPE  WaveFormRec  IS  RECORD 
freq_ohni  :  INTEGER: 
freajoana  :  INTEGER: 
phasel_code:  INTEGER; 
phase2_:ode INTEGER: 
fnci  :  mtiRec ; 

msle  :  msleRec ; 

innib_freq_chni :  INTEGER; 

END  RECORD; 

TYPE  F_to_R  IS  ACCESS  WaveFormRec; 

TYPE  InfoWaveForm  IS  ARRAY ( I . .max_dwells )  OF  F_to_R; 

waveform:  InfoWaveForm; 

END  tab8; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 
--  PURPOSE:  Common  Memory  Interface 
--  NAME:  F_to_R  ...  TAB8.PKG 

--  This  interface  data  structure  contains  the  frequency  and  waveform 
--  information  required  by  the  Radar  Scheduler  Process  to  complete 
--  formatting  of  selected  radar  dwells. 

pragma  arithcheck(of f ) ;  pragma  debug(off) ; 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rancecheck(on) ; 

PACKAGE  BODY  *ab8  IS 

i:  INTEGER; 


BEGIN 

FOR  i  IN  1 . .max_dwells  LOOP 

waveform(i) :=  NEW  WaveFormRec; 
END  LOOP; 

END  tab8 ; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 
--  PURPOSE:  Common  Memory  Interface 
--  NAME:  L_to_R  ...  TAB9.LIB 

--  This  interface  data  structure  contains  the  flag  which  indicates 
--  reset  time  for  the  track  counter.  This  flag  is  used  by  the  Radar 
--  Scheduler  Process  to  format  track  dwells. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangechecfc(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  :ab9  IS 

trk_cim_ctr_resec :  300LZAN; 


END  tab9; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 

—  MODULE  TYPE:  External  Table 

—  PURPOSE:  Common  Memorv  Interface 

—  NAME:  Missile  Downlink  Message  . . .  TAB10.LIB 

--  This  table  holds  the  communication  information  required  for 

—  downlink  data  from  own  ship's  SM-2  missiles. 

pragma  arithcheckfoff ) ;  pragma  debug(off); 
praama  enumtab(of f ) ;  pragma  rangecheck(of f ) ; 

@  pragma  arithcheck(on) ;  pragma  debug'(on) ; 

@  pragma  enumtab(on) ;  pragma  rangecheck(on) ; 

PACKAGE  -ablO  13 


num_mssl_msgs :  CONSTANT  INTEGER:3  10:  --  nor.  previously  defined,  10? 

TYPE  DwnlinkRec  IS  RECORD 
prt_one  :  INTEGER; 
prt_cwo  : INTEGER; 
prr_three : INTEGER; 
prr_four  : INTEGER; 
prr_rive  : INTEGER; 
prt~six  : INTEGER; 
nrt_seven : INTEGER ; 
prr  e iant: INTEGER; 

END  RECORD'; 

TYPE  PtrMsslDwnlnk  IS  ACCESS  DwnlinkRec; 

TYPE  DwnlnxArray  IS  ARRAY (1 . .num_mssl_msgs)  OF  PtrMsslDwnlnk; 

mssi_dwnlnk :  OwnlnkArray ; 

END  tablO  : 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 

—  MODULE  TYPE:  External  Table 

—  PURPOSE:  Common  Memory  Interface 

--  NAME:  Missile  Downlink  Message  ...  TAB10.PKG 

--  This  table  holds  the  communication  information  required  for 
--  downlink  data  from  own  ship's  SM-2  missiles. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangecheck(off) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 
d  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  BODY  tab 10  IS 

1:  INTEGER: 

BEGIN 

FOR  1  IN  1..  num_mssi_Tisgs  LOOP 

ms3l_dwnlnk(x)  :•=  MEW  DwniinkRec; 

END  LOOP; 

END  :abl0; 
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—  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 

—  PURPOSE:  Common  Memory  Interface 
--  NAME:  R_to_S  ...  TABll . LIB 

--  This  interface  data  structure  contains  the  replenishment  flags 
--  which  inform  the  Search  Management  Process  which  search  queues 
--  require  filling.  The  Radar  Scheduler  Process  sets  the  flags  as 
--  necessary  when  it  has  used  a  preset  number  of  search  request 

—  beams. 

pragma  arithcheck(of f ) ;  pragma  debug(off))  ; 
praama  enumtab(off ) :  pragma  rangecheck(of f ) ; 

@  pragma  arithcheck(cn) ;  pragma  aebug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 


PACKAGE  tab 11  IS 

TYPE  RtoS  IS  RECORD 

hs_que_repln :  BOOLEAN; 
ahs_que_rsoln :  BOOLEAN; 
END  RECORD ; 

TYPE  RtoSPtr  IS  ACCESS  RtoS; 
R_tO_S:  RtoSPtr; 

END  tabll; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  11  Oct  86 
--  MODULE  TYPE:  External  Table 
--  PURPOSE:  Common  Memory  Interface 
--  NAME:  R_to_S  ...  TABll.PKG 

--  This  interface  data  structure  contains  the  replenishment  flag 
—  which  inform  the  Search  Management  Process  which  search  queue 
--  require  filling.  The  Radar  Scheduler  Process  sets  the  flags  as 
--  necessary  when  it  has  used  a  preset  number  of  search  request 
--  beams. 

pragma  arithcheck(off ) ;  pragma  debug(off))  ; 
pragma  enumtab(off) ;  pragma  rangecheck(off ) ; 
pragma  ariihcheck(on) ;  pragma  debug(on); 
pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  30DY  tabll  IS 

BEGIN 

R_to_S :=  NEW  RtoS; 

END  tabll; 
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cn  cn 


--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  common  memory  interface 
--  NAME:  R_to_0  ...  TAB32.LI3 

--  This  table  is  the  interface  between  the  Radar  Scheduler  Process  and  the 
--  Radar  Output  Process. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangechecfc(of f ) ; 

@  p'ragma  arithcheck(on) ;  pragma  debug(on)  ; 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  tab32  _S 


TYPE  DwlData  IS  RECORD 
mode 
face 

sub_moae 
awl_idx 
beam_puroose 
dwl_3cart_rdx 
doc t_unolnk  gates 
clutter  unbTnk_aates 
END  RECORD: 


INTEGER ; 

~UTEGER ; 

ARRAY {l'.  .2)  OF  INTEGER ; 
INTEGER; 

INTEGER; 

INTEGER ; 

INTEGER ; 

INTEGER ; 


TYPE  RtoO; 

TYPE  PtrRtoO  IS  ACCESS  RtoO; 
TYPE  RtoO  IS  RECORD 

dvl  aata  :  DwlData: 
link  :  PtrRtoO: 

END  RECORD; 


R_CO_0:  PtrRtoO; 

TYPE  ROPtrArrav  IS  ARRAY(1..2)  OF  PtrRtoO; 
ptr_r_to_o:  ROftrArray; 

END  tab32; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  23  Oct  86 
--  MODULE  TYPE:  external  table 
--  PURPOSE:  common  memory  interface 
--  NAME:  R_to_0  ...  TAB32.PKG 

--  This  table  is  the  interface  between  the  Radar  Scheduler  Process  and  the 
--  Radar  Output  Process. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangecheck(of f ) ; 

@  praqma  arithcheck(on) ;  pragma  debug(on); 

<§  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  BODY  tab32  IS 

BEGIN 

ptr_r_to_o<l )  .-=  NEW  RtoO: 
ptr_r_co_a< 2 ) NEW  RtoO: 
ptr_r_to_o( I ) . link:=  null; 
ptr_r_to_o ( 2 ; . link :=  null; 

END  tao32; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  data  buffer 

--  PURPOSE:  internal  data  structure 

--  NAME:  Output  Control  Channel  Buffer  ...TAB40.LIB 


--  This  interface  data  structure  is  a  buffer  between  the  Radar  Control 
--  program  and  the  Radar  Channel  program.  It  communicates  with  the 
--  Radar  Scheduler  and  Radar  Output  processes.  The  Radar  Channel  program 
--  uses  the  data  to  process  commands  for  the  SPY-1  radar. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(cn) ;  pragma  debug"(on); 

§  pragma  snumtab(on);  pragma  rangecheck^on) ; 

PACKAGE  tab40  IS 


TYPE  CntrlWord  IS  RECORD 
rdr_xmsn_on  : 

adi  detect_enable  : 
sdlE_canx_on  : 

chnl_a_viaeo  : 

chnl_b_video  : 

freq_group_sicr  : 

rng_3calz.hg_3nab.ie  •. 

tl_subchni3isaDia  : 

t2_3ubcnni_disable  : 
t3_3ubchnl_disanie 
c4_3ubchnl_disable  : 
subchnl_veight_enable : 
citr_lock_ops  : 

cltr_iock_err  : 

END  RECORD; 


BOOLEAN ; 
BOOLEAN; 
BOOLEAN; 
BOOLEAN ; 
BOOLEAN ; 
BOOLEAN ; 
BOOLEAN : 
BOOLEAN ; 
BOOLEAN : 
BOOLEAN ; 
BOOLEAN ; 

BOOLEAN ; 
BOOLEAN ; 
BOOLEAN ; 


TYPE  FreaGroupSelect  IS  RECORD 
pri_m*ode_a  :  INTEGER; 
b_submode  :  INTEGER; 
c_submode  :  INTEGER; 

END  RECORD; 


TYPE  OaType  IS  RECORD 

cntrl_word  :  CntrlWord; 

f re q_group_s elect  :  FreaGroupSelect; 
data_block_code  :  INTEGER; 

END  RECORD; 

TYPE  ObType  IS  RECORD 

detectl_thrsld  :  INTEGER; 
detect2_thrsld  :  INTEGER; 
detect3_thrsld  :  INTEGER; 
sdlb_thrsld  :  INTEGER; 

END  RECORD; 

TYPE  OcType  IS  RECORD 

mnlb_thrsldl  :  INTEGER; 

cvr_pulse  thrsldl  :  INTEGER; 
satl_thrsTd  :  INTEGER; 

sat2_thrsld  :  INTEGER; 

END  RECORD; 

TYPE  OdType  IS  RECORD 

ratio_thrsld  :  INTEGER; 
limit_thrsld  :  INTEGER; 
cltr_thrsld  :  INTEGER; 

END  RECORD; 

TYPE  OeType  IS  RECORD 
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comptr_lock  init  :  INTEGER; 
truncl_thrsld  :  INTEGER; 
trunc2_thrsld  :  INTEGER; 

END  RECORD; 

TYPE  OfType  IS  RECORD 

phsel_code  :  INTEGER; 
phse2_code  :  INTEGER; 
phse3_code  :  INTEGER; 
phse4_code  :  INTEGER; 

END  RECORD; 

TYPE  OgType  IS  RECORD 
fdbkl  :  INTEGER; 
fdbk2  :  INTEGER; 
rdbkB  :  INTEGER; 
fdbk4  ;  INTEGER; 

END  RECORD; 

TYPE  OhTvpe  IS  RECORD 
priljmti  s  INTEGER; 
pri2_mti  :  INTEGER; 

END  RECORD; 

TYPE  QiTvpe  IS  RECORD 

■rnc.rlj.bit  :  300L3AN: 

dvl_i_start_cime  :  INTEGER; 
dv l_2_s car c_ time  :  -IJTEGER; 

END  RECORD; 

TYPE  OjTvpe  IS  RECORD 

cntrl_bit  ; 

doct_l^ur.blnk_scarc  ; 
suDcnnI_fraq_arouD  : 

END  RECORD; 

TYPE  OkType  13  RECORD 

cntrl_bit  ; 

doct  l_unblnk_stop  : 
fixe3_atten_cntrl  ; 
stc_cntrl  s 

END  RECORD; 

TYPE  OlType  IS  RECORD 

cntrl_bit  : 

doct_2_unblnk_start  : 
xmit  freq  ; 

rcv_7req  s 

END  RECORD; 

TYPE  OmType  IS  RECORD 
cntrl_bit 

doc t_2_unb Ink  s top 
face  ; 

fore_beam_alarm_inhib :  INTEGER; 
cos_alphal_mn_array  :  INTEGER; 

END  RECORD; 

TYPE  OnType  IS  RECORD 

cntrl_bit  :  BOOLEAN; 

cltr  l_unblnk_start  :  INTEGER; 
af t_Heam_alert  inhib;  INTEGER; 
cos_alpha2_sdlB_blnk_ary ;  INTEGER; 

END  RECORD; 

TYPE  OoType  IS  RECORD 

cntrl_bit  :  BOOLEAN; 

cltr  l_unblnk_start  :  INTEGER; 
cos_Betal_mn_array  :  INTEGER; 


BOOLEAN ; 
INTEGER ; 
INTEGER ; 


BOOLEAN ; 
INTEGER; 
INTEGER; 
INTEGER; 


BOOLEAN ; 
INTEGER; 
INTEGER; 
INTEGER; 


BOOLEAN ; 
INTEGER; 
INTEGER; 
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END  RECORD; 


TYPE  OpType  IS  RECORD 

cntri_bit  :  BOOLEAN; 

cltr  2_unblk  strt  :  INTEGER; 

cos_Be ta2_sdlb_blnk_ary :  INTEGER ; 
END  RECORD; 


TYPE  OqType  IS  RECORD 
cntrl_bit 
cltr_2_unblk_stop 
elev_sector 
dply_ctrl 
trk_num 
END  RECORD: 


BOOLEAN ; 
INTEGER; 
INTEGER ; 
INTEGER ; 
INTEGER ; 


TYPE  OrType  IS  RECORD 

trk_gare_s zrt  :  INTEGER; 
dDlv_eiev  ;  INTEGER; 
END  RECORD; 


TYPE  OsType  IS  RECORD 

video  axtnc  ;  INTEGER; 
doly_grD_aic*  •  INTEGER; 
dblv_az'im  :  INTEGER; 

END  RECORD: 

TYPE  OtTvpe  IS  RECORD 
otmsb':  INTEGER; 
oclsb  :  INTEGER; 

END  RECORD; 

TYPE  OtArray  IS  ARRAY(1..16)  OF  OtTvpe; 

TYPE  OccoTvDe; 

TYPE  PtrOccb  IS  ACCESS  OccbTvoe ; 

TYPE  OccbType  IS  RECORD 
oa  :  "OaType; 

ob  :  ObType ; 

oc  :  OcType; 

Od  ;  OdType; 

oe  :  OeType; 

o_f  ;  OfType; 

oq  ;  OqType; 

oh  :  OnType ; 

oi  :  OiType; 

oi  ;  OjType; 

ok  :  OkType; 

ol  :  OiType; 

om  ;  OmType; 

on  :  OnType; 

oo  ;  OoType ; 

op  ;  OpType ; 

oq  ;  OqType ; 

o_r  ;  OrType; 

OS  ;  OsType; 

ot  ;  OtArray; 

link  :  PtrOccb; 

END  RECORD; 

occb ;  PtrOccb; 

TYPE  OCCBPtrArray  IS  ARRAY (1.. 2)  OF  PtrOccb; 

occb_ptr:  OCCBPtrArray; 

END  tab40; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  23  Oct  86 

--  MODULE  TYPE:  data  buffer 

--  PURPOSE:  internal  data  structure 

--  NAME:  Output  Control  Channel  Buffer  ...TAB40.PKG 


--  This  interface  data  structure  is  a  buffer  between  the  Radar  Control 
--  program  and  the  Radar  Channel  program.  It  communicates  with  the 
--  Radar  Scheduler  and  Radar  Output  processes.  The  Radar  Channel  program 
--  uses  the  data  to  process  commands  for  the  SPY-1  radar. 

pragma  arithcheckCoff ) ;  oragma  cebug(off) ; 
pragma  enumtab(off ) ;  pragma  rangechecfc(off) ; 

§  p'ragma  ariohcheck(on) ;  oragma  debug(on)  ; 

?  pragma  anumtab<,on) ;  pragma  rangecheck(on) ; 

PACKAGE  BODY  Cao40  IS 

3EGIN 

occb_ptr (1  )  :=  NEW  OccbType; 
occb^ocr!,!)  :=  MEW  OccoType; 
occo_ocr ( 1 )  . link:35  null;* 
occb_ptr;2) .link:=  null; 

END  :ap40 • 
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APPENDIX  B 

GLOBAL  SOURCE  CODE 


--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  22  Oct  86 
--  MODULE  TYPE:  Global  data 

--  PURPOSE:  System's  Data  Structure  declarations 
—  NAME:  GLOBAL  DECLARATIONS  ...  GLOBAL . LIB 

pragma  arithcheckCoff ) ;  pragma  debug(off ) ; 
pragma  anumtab(off) ;  bragma  rangecneck(orf) ; 
@  pragma  arithcheck(on) ;  pragma  deoug(cn; ; 

pragma  enumtab(on) ;  pragma  rangecheck(on)  ; 

PACKAGE  global  IS 

--SES  CONSTANTS 


numb_ events CONSTANT  INTEGER  :=  28; 
buff .size:  CONSTANT  INTEGER  : =10  r 
infinity:  CONSTANT  INTEGER  :=  32000; 
numb_procs:  CONSTANT  INTEGER  :=  21; 


--orccess  identifiers 


CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
CONSTANT  INTEGER 
_  CONSTANT  INTEGER 
k_pid:  CONSTANT  INTEGER 
l_pid:  CONSTANT  INTEGER 
m_pid:  CONSTANT  INTEGER 
w  Did:  CONSTANT  INTEGER 
x_pid:  CONSTANT  INTEGER 
h_pid :  CONSTANT  INTEGER 
o_pid:  CONSTANT  INTEGER 
i_pid:  CONSTANT  INTEGER 
p_pid:  CONSTANT  INTEGER 
t_pid:  CONSTANT  INTEGER 
s_pid:  CONSTANT  INTEGER 
r_pid:  CONSTANT  INTEGER 
main.id:  CONSTANT  INTEGER 
idle  id:  CONSTANT  INTEGER 


a_pia: 
c_pid: 
bjpid : 
d_pid: 
e_pid : 
X_P Id: 


-  u . 


o; 

7; 

8; 

9; 

10 
11 
12 

13 

14 

15 

16 
17 
18; 

:=  19; 
:=  20; 


— event  count  identifiers,  reserved  event  count  identifiers:  0,1 


main  event.id:  CONSTANT  INTEGER 
display.evc  id:  CONSTANT  INTEGER 
time_count_id:  CONSTANT  INTEGER 
idle  event  id:  CONSTANT  INTEGER 


ea_i<3:  CONSTANT 
ec_id :  CONSTANT 
eb_id:  CONSTANT 
ed_id:  CONSTANT 
ee_id:  CONSTANT 
ef_id:  CONSTANT 
ek_id:  CONSTANT 
el_id:  CONSTANT 
em_id:  CONSTANT 
ew_id:  CONSTANT 
ex_id :  CONSTANT 
eh_id:  CONSTANT 


INTEGER 

=  3; 

INTEGER 

=  4; 

INTEGER 

=  5; 

INTEGER 

=  7; 

INTEGER 

=  8; 

INTEGER 

=  9; 

INTEGER 

=  10; 

INTEGER 

=  11; 

INTEGER 

=  12; 

INTEGER 

=  13; 

INTEGER 

=  14; 

INTEGER 

=  15; 

1? 

2; 

6; 

20; 


,2,6,20 
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H  M 


eo_id:  CONSTANT  INTEGER  :=  16; 

ei_id:  CONSTANT  INTEGER  :  =  17; 

ep_id:  CONSTANT  INTEGER  :=  18; 

et_id:  CONSTANT  INTEGER  :=  19; 

es_id:  CONSTANT  INTEGER  :=  21; 

er_id:  CONSTANT  INTEGER  :=  22; 

--common  service  routines 

FUNCTION  clock  RETURN  INTEGER; 

FUNCTION  rand  RETURN  INTEGER; 

PROCEDURE  ipl ; 

PROCEDURE  await(proc_id , event_id( event_value :  IN  INTEGER); 
PROCEDURE  advance (proc_id,event_id:  IN  INTEGER); 

FUNCTION  ticket  RETURN  INTEGER; 

PROCEDURE  disable; 

PROCEDURE  enaole ; 

--System's  Data  Objects 

TYPE  EveValArray  IS  ARRAY  (0 . .numb_events)  OF  INTEGER; 
event_val_cnt  : EveValArray ; 

TYPE  process  IS  RECORD 
status  :  INTEGER; 

context  ;  INTEGER; 

count  :  INTEGER; 

event  ;  INTEGER; 

ND  RECORD; 

YPE  ProIabArray  IS  ARRAY  (0 . ,numb_procs)  OF  process; 
prcs_tble  ProIabArray; 

ND  glooal; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  26  Nov  86 
--  MODULE  TYPE:  global  package  body 
--  PURPOSE:  to  define  common  service  routines 
--  NAME:  global  ...  GLOBAL. PKG 

pragma  arithcheck(off ) ;  pragma  debug(offi); 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  Longops , tabO , tabl , tab2 , tab7 ; 

PACKAGE  30DY  global  IS 

USE  Longops , iaoO , tabl , taD2 , tab7  • 

--  OWNER:  AEGIS  Moctelina  Group 
--  DATE  OF  LAST  UPDATE  .•''l  Dec'  35 
--  MODULE  TYPE:  common  service  routine 
--  PURPOSE:  generate  a  random  number 
--  NAME:  RAND  ...csr5 

--  This  oseudo-random  number  generator  uses  the  songruence  algorithm 
--  to  generate  a  list  of  random  numoers  with  a  period  approximately 
--  equal  to  11 1"  .  The  eauation  is  of  the  form: 

M(n+1)  -  nod  C(A  '  .-1(11)  +  3)  T) 

INTEGER:-  -1; 


FUNCTION  rand  RETURN  INTEGER  IS 

a:  INTEGER  557- 

O :  INTEGER  37; 

t:  INTEGER  31099: 

seed:  INTEGER  :-  19879; 
y:  Lcng_In eager ; 

BEGIN 

IF  x=-l  THEN 
x:=  seed; 

END  IF; 

--  compute  the  random  number 
y :=  Ladd(Lmul(Lint(a) , Lint (x) ), Lint (b) ) ; 
X:=L_to_int(Lmod(y,Lint(t) ) ) ; 

RETURN  X; 

END  rand; 
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OWNER:  AEGIS  Modeling  Group 

DATE  OF  LAST  UPDATE:  30  Nov  86 

MODULE  TYPE:  external  initialization  routine 

PURPOSE:  initialize  the  priority  event  list  for  the  Radar  Scheduler  Model 
NAME:  Initialize  the  Radar  Event  Priority  List...csr6 

This  routine  initializes  the  Priority  Event  List  which  is  used  by  the 
Radar  Scheduler,  Search  Management  and  Track  Management  processes  to 
request  and  schedule  radar  dwells. 


PROCEDURE  ipl  IS 
i:  INTEGER; 


BEGIN 

for  i  in  i..max_pri  LOOP 

pri_lst(i) . status :=  false; 
pri~Ist('i)  .b_pri  :  =  i; 
pri_lst(i) .c_pri:=  i; 
pri_lst(l) .ltX:=  0; 
ori_lst( i) .slct_£lg:=  false; 
prillst(i) .nxt:=  ifl  ; 

IF  ' ( i<=8)  OR  ( ( i>=10)  AND  (i<=13)))  THEN 
on  Ist( i)  . allwd  Itx 100; 

ELSlF  (Ti>=l4)  AND  fl<=21 ) )  THEN 
ori  lst(i) .  aiiwd_it:::=  500; 

ELSiF  ■"1=9 )  THEN 

ori  lst(i). allwd  ltx:  =  25; 

ELSxF  ,1=22)  THEM 

ori_isc( i) . ailwd_itx:=  50; 

ELSE 

on_lsT;(i)  .allwd_lt:-:;=  infinity; 

END  "IF; 


IF  ( (i<lo_ennnc )  CR  (i>22))  THEN 
pri_lst(i) .enhnc :=  false; 
ELSE 

pri_lst(i) .enhnc :=  true; 

END  IF; 


IF  ( (i<=3) 
pn_lst 
pri_lst 
pri_lst 
pri_lst 
pri  1st; 

ELS  IF  (7  i=4 
pri_lst ' 
pri_lst 
pri_lst 
pri_lst 
pri_lst 
pri_lst 
pri  lst< 

ELS  IF  (7i=9 
pri_lst i 
pri_lst 
pri_lst 
pri_lst 
pri_lst 
pri  1st 


OR  ( (i>=10)  AND  (i<=13) )  OR  (i>=23))  THEN 
'i) .max_noaes :=  5; 
i).que_id:=  special_request ; 
i)  .que_ptr  .kind-.=  special_request ; 

J  .que_ptr.Snode:=  NEW  SearchNode; 
i) .que  Dtr.Snode.nxt:=  null; 

OR  ( (i>=6 )  AND  (i<=8) )  OR  ((i>=14)  AND  ( i<=21 ) ) )  THEN 
i ) . max_node  s : =  5 ; 
i).que_id:=  track; 
i) .que_ptr . kind:=  track; 
i) .que_ptr .Tnode :=  NEW  TrackNode; 
i) .que_ptr.Tnode.info.p_trk:=  NEW  TrkFile; 
i) .que_ptr .Tnode . info. p_trk.beam_data :=  NEW  TrkData; 
i) .que  Dtr. Tnode .nxt :=  null; 

OR  ( 1=22) )  THEN 
i) .max_noaes :=  10; 
i).que_id:=  searcn; 
i) .que_ptr .kind:=  search; 
i)  .que_ptr.Snode.*=  NEW  SearchNode; 
i) .que_ptr.Snode.info:=  NEW  SrchData; 
i) .que_ptr.Snode.nxt:=  null; 


pri_lst(i) .max_nodes :=  2j 
pri_lst( i ) .que_id:=  missile; 
pri_lst( i) .que_ptr .kind:=  missile; 
pri_lst(i) .que_ptr .Tnode :=  NEW  TrackNode; 
pri_lst (i) .que_ptr .Tnode .nxt :=  null; 
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ND 


END  IF; 


Z( 


___  u 

i~lst 

I.  3  H 
L_l3t 
L_Lst 
:_Is  c 
L_.SC 
1  .Sl 


n  event  names 

I)  .eventnm:= 
’2) .eventnm:= 

3)  .eventnm:= 

4 )  . eventnm  :  = 

5)  . eventnm := 
'6 ) . eventnm := 
7 ) . eventnm := 
3) . eventnm := 

9)  . eventnm := 

10)  . eventnm:5 

II )  . eventnm.-5 

12)  .eventnm:5 

13)  .eventnm:5 

14)  . eventnm:5 

15)  .eventnm:5 

16 )  . eventnm:5 

17 )  .eventnm:5 
IS) . eventnm :5 
19) . eventnm : 5 

.eventnm:5 
.eventnm:5 
.eventnm:5 
.eventnm : 5 
. eventnm : 5 
} . eventnm:5 
26 )  .eventnm:5 


to  each  priority 
'A-EVENT  -  ECM  BU: 


END  LOOP; 

--reset  "nxt"  on  last  element  in  Priority  List  to  point  to  0 
pri_lst(max_pri) .nxt :=  0; 

--  assi 
pri_lst 
pri_lst 
pri_lst 
pri_lst 
pri_lst 
pri_lst 
pri_lst 
ori_lst 
pri_ist 
pri_lst 
pri_lst 
pri_lst 
pri_lst 
pri  1st 
pri_ist 
pri_lst 
bri_lst 
pn_lst 


21) 

2  2  N 

O  2)  \ 


24) 


'B-EVENT  - 
'C-EVENT  - 
'D-EVENT  - 
'E-EVENT  - 
F-EVENT  - 
'G-EVENT  - 
H- EVENT  - 
1 1 - EVENT  - 
"J- EVENT 
11 K- EVENT 
"L-EVENT 
"M-EVENT 
"N-EVENT 
"0- EVENT 
"?- EVENT 
"0- EVENT 
"R- EVENT 
"S- EVENT 
"T- EVENT 
"U- EVENT 
"V- EVENT 
"W- EVENT 
:l  M-EVENT 
Y-  EVENT 
"2- EVENT 


RNTHROUGH" ; 

TARGET  DEFINITION"; 

SPFCTAL  TEST"  • 

ENGAGED  HOSTILE  TARGET"; 

OWN  SM-2  MISSILE  GUIDANCE"; 
PRE-ENGAGED  HOSTILE  TARGET"; 
HIGH  PRI  TRACK  TRANSITION"; 
HIGH  PRI  TRACK  CONFIRMATION" ; 
HORIZON  SEARCH" ; 

SPECIAL  ECM  EURNTHROUGH" ; 
SPECIAL  TARGET  DEFINITION"; 
SPECIAL  MANUAL  SCAN" ; 

SPECIAL  TARGET  ACQUISITION"; 
CONFIRMED  HOSTILE  TRACK"; 
ASSUMED  HOSTILE  TRACK" ; 
UNEVALUATED  TRACK" ; 
CONTROLLED  FRIENDLY  TRACK" • 
TRACK  CONFIRMATION" ; 

TRACK  TRANSITION" - 
ASSUMED  FRIENDLY  TRACK" • 
CONFIRMED  FRIENDLY  TRACK" ; 
ABOVE  HORIZON  SEARCH" ; 
SPECIAL  ABOVE  HORIZON  SEARCH' 
SIMULATION  DWELL" ; 

DIAGNOSTIC  DWELL" ; 

DUMMY  DWELL" ; 


-pi; 
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OWNER:  AEGIS  Modeling  Group 

DATE  OF  LAST  UPDATE:  24  Jun  86 

MODULE  TYPE:  common  service  routine 

PURPOSE:  simulates  a  real  time  millisecond  clock 

NAME :  clock  . . . csr7 

This  common  service  routine  simulates  a  real  time  millisecond  clock, 
when  the  routine  is  invoked  the  variable  "time"  is  incremented  by 
one.  The  new  value  of  time  is  then  RETURNed  to  the  invoking  PROCEDURE. 


time:  INTEGER; 

FUNCTION  clock  RETURN  INTEGER  IS 
BEGIN 

iime:=time  +  1; 

RETURN  time; 

END  clock; 
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--  The  following  functions  and  procedures  are  only  stubs  for  testing 

PROCEDURE  await(proc_id, event_id, event_val :IN  INTEGER)  IS 
BEGIN 
null; 

END  await; 

PROCEDURE  advance (proc_id,event_id: IN  INTEGER)  IS 
BEGIN 

null; 

END  advance; 

FUNCTION  ticket  RETURN  INTEGER  IS 
BEGIN 

RETURN  0; 

END  ticket; 

PROCEDURE  disable  IS 
BEGIN 

null ; 

END  disable ; 

PROCEDURE  enable  IS 
BEGIN 

null ; 

END  er.aoie ; 

--  initialisation 
BEGIN 

time : -  - I ; 

END  gioDai; 
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APPENDIX  C 

RADAR  SCHEDULER  SOURCE  CODE 


--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  29  Aug  86 

--  MODULE  TYPE:  Process  vers  6.0 

--  PURPOSE:  Model  the  Radar  Scheduler  Function 

--  NAME:  Radar  Scheduler  ...  RRCM.LI3 

--  The  Radar  Scheduler  selects  requested  beams  from  queues 
--  by  the  Search  Management  and  Traci:  Management  functions. 
--  selected  beams  are  "then  processed  ana  formatted  into  dwe 
--  dwells  are  transmitted  to  the  Radar  Output  function  and 
--  into  the  Channel  Output  Suffer.  Seams  are  selected  for 
--  processing  based  on  a  priority  scheme. 

pragma  arithcheck(orf ) ;  pragma  debug(orf) : 
braama  enumtao ( of f ) ;  pragma  rangechecxi off ) ; 

<?  p'ragma  arithcneckl on) ;  pragma  deoug(on)  ; 

■?  pragma  enumtab(on);  pragma  rangecnec!:(on)  ; 

PACKAGE  rrcm  IS 

PROCEDURE  radar_scheduier ; 

END  rrcm; 


Generated 

The 

ils .  The 
are  oacked 
dwell 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  2  Dec  86 

--  MODULE  TYPE:  Process  vers  6.0 

--  PURPOSE:  Model  the  Radar  Scheduler  Function 

--  NAME :  Radar  Scheduler  ...  RRCM.PKG 

--  The  Radar  Scheduler  selects  requested  beams  from  queues  generated 
--  by  the  Search  Management  and  Track  Management  functions.  The 
--  selected  beams  are  then  processed  and  formatted  into  dwells.  The 
--  dwells  are  transmitted  to  the  Radar  Output  function  and  are  packed 
—  into  the  Channel  Output  Buffer.  Beams  are  selected  for  dwell 
--  processing  based  on  a  priority  scheme. 


pragma  arithcheck(of f ) ;  pragma  debug(off ) ; 
pragma  enumcab(oft) ;  pragma  rangecheck(off ) ; 

9  pragma  arithcheck(on) ;  pragma  debug'(on); 

0  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  Io , Util , global , tabO , tabl , tab2 , tab4 , tab7 , tab32 , tab40 , rsmO , rsm2 , 
rsm3 , rsm5 , rsm9 , rsmlO , rsml2 , rsml3 , rsml4; 

PACKAGE  BODY  rrcm  IS 

USE  Io ,  'Jtil ,  global ,  tabO  ,  labi  ,  tab2  ,  iab4  ,  cab7  ,  aab32  ,  iab4Q  ,  rsmO  ,  rsm2  . 
rsm3 , rsm5 , rsm9 , rsmlO , rsml2 , rsm!3 , rsmi4  r 

PROCEDURE  raaar_scneduler  IS 

i:  INTEGER  :•=  0; 
j:  INTEGER 2; 

--beam  selection  module  CONSTANTS 

rdrint:  CONSTANT  INTEGER :  =  21; 
srch_que:  CONSTANT  INTEGER :=  1; 
sr_que:  CONSTANT  INTEGER :=  2; 
srch_dwls:  CONSTANT  INTEGER :=  9; 
sr_dwls :  CONSTANT  INTEGER :=  2; 
rdr_rsrcs:  CONSTANT  INTEGER :=  100; 
trk  que:  CONSTANT  INTEGER :=  3; 
mssl  que:  CONSTANT  INTEGER :=  4; 
trk  Hwls:  CONSTANT  INTEGER :=  10; 
mssT_dwls :  CONSTANT  INTEGER :=  5; 

rru  :  INTEGER; 

sru  :  INTEGER; 

sra  :  INTEGER; 

tot_dwl_schd:  INTEGER; 
tot  dwls  :  INTEGER; 
srcE_sra  :  INTEGER; 
trk  sra  :  INTEGER; 
mssT_sra  :  INTEGER; 
sr_sra  :  INTEGER; 
hwc  :  boolean; 

et  :  INTEGER; 

rtim  :  INTEGER; 
oltim  :  INTEGER; 
dltatim  :  INTEGER; 


BEGIN 

Delete("RSOUT.Txt"); 

Create (Text , "RSOUT .Txt" , Write_Only) ; 
Open (Text, "RSOUT .Txt" ,Write_Only) ; 

WHILE  (i  <  A_to_R . op_doct .mintvls )  LOOP 
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.  ■  f-  '*■  / 

intvl_num:=  i; 


i  +  1 


--  advance  the  radar  loop  event  counts 

advance (r_pid,es_id) ; 
advance (r_pid.et_id) ; 

rtim:=  clock();  --  from  csr7  in  global. pkg 

--  swap  external  dwell  buffers 
swap(buff_ptr ,cm_ptr , j ) ;  --  from  rsm2.pkg 

--  enhance  event  priorities 
enhance (et);  --  from  rsm3.pkg 

--  resynchronization  module  never  written 
--  rsm4.pkg 

—  begin  beam  selection 

--  initialize  the  priority  list  traversal  constraints 
et:=  0; 
rru:=  0; 

tot^dw^schd^  0; 
srcK_sra:=  srch_dwls; 
zrk_sra:-=  trk_dwLs; 

3  r_s  ra  :•=  3r_awis; 
mssl  sra:=  mssl_dwls; 

toc_3wls :=  srch_dwls  +  trk_dwls  +  sr_dwls  +  mssl_dwls; 

--  zraverse  the  Priority  List 

pp 1 :  —  1; 

WrilLE  (.(et  <  rdrint  )  AND  (rru  <  rdr_rsrcs)  AND 

( tot_dwl_3cna  <  tct_dwls)  AND  (ppi  /=  0))  LOOP 

--  check  for  an  emDtv  queue 
IF  pri_lst(ppl) .status  ’THEN 

--  traverse  the  priority  event  queue 

--  initialize  the  event  queue  traversal  constraints 

sru.-=  0; 

CASE  pn_Lst(ppl)  .que_id  IS 

WHEN  search  =>  sra:=  srch_sra; 

WHEN  special_request  =>  sra:=  sr_sra; 

WHEN  track  =>  sra:=  trk_sra; 

WHEN  missile  =>  sra:=  mssl_sra; 

END  CASE; 

--  select  a  search  type  beam  or  a  track  type  beam 
CASE  pri_lst(ppl) .que_id  IS 

WHEN  search  |  special_request  => 


--traverse  the  search  event  queue 


--  get  a  Radar  Event  node 

r-.=  get_rect_node( ) ;  --  from  RSM5B 

--  insert  beam  information  into  the  node 
r.srch^_dwl.ALL:=  sp.  info.  ALL; 
r.beamld:=  r . srch_dwl.bid; 

--  format  the  selected  beams 
--  do  supplementary  processing 
--  rsm6  not  writen 
--  do  face  assignment 
--  rsm7  not  written 
--  radar  doctrine 
--  rsm8  not  writen 
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--  satisfy  the  hardware  constraints 
hw_constraint(pri_lst(ppl) .que_id, rru, r . dru, hwc) ; 

IF  hwc  THEN 

--  indicate  to  the  Priority  List  that  this 
--  event  has  been  scheduled 
pri_lst(ppl) • slct_flg:=  TRUE; 

--  fill  the  external  table  module 
fill_ext_tab(buf f_ptr , occb_ptr( j ) ,cm  otr, 

ptr_r_to_o("5)  ,  r .  ocb_cfata) ;  --  rsmlC 

--  insert  the  dwell  at  the  end  of  the  Radar 

--  Event  Control  Table  list 

llena(r , rectjotr) ;  --  from  rsm5a.pkg 

--  load  the  evaluation  module 
--  rsmll  never  written 

--  update  the  used  resources 
IF  (pri_lst(ppl) .que_id  =  search)  THEN 
srch_sra:-=  srcn_sra  -  1; 

ELSE 

sr_sra:-=  sr_sra  -  1; 

END  IF: 

tot_dwl_schd:=  tot_dwl_schd  +  1; 
sru:=  sru  +  1; 

ELSE 

—  hardware  constraints  have  not  been  satisfied 
f ree_rect_node ( r) ;  —  from  rsm5c.pkg 

END  IF; 

--  get  next  event  in  search  or  special  request 

--queue 

sp :=  sp.nxt; 

END  LOOP; 

--traverse  the  search  event  queue 
tp:=  pri_lst (ppl) . que_ptr .Tnode ; 

WHILE  (sp  /=  null)  LOOP 

--  get  a  Radar  Event  node 

rs=  get_rect_node ( ) ;  --  from  rsm5b.pkg 

--  insert  beam  information  into  node 
r . t  rk_dwl . ALL : =  tp . inf o . p_t r k . beam_da  ta . ALL ; 
r.beamid:=  tp. info. bid; 

--  format  the  selected  beam 
--  do  supplementary  processing 
--  rsm6  not  written 
--  do  face  assignment 
--  rsm7  not  written 
--  radar  doctrine  module 
--  rsm8  not  written 

--  satisfy  the  hardware  constraints 
hw_constraint(pri_lst(ppl) .que_id, rru, r. dru, hwc) ; 

IF  hwc  THEN 

--  indicate  to  the  Priority  List  that  this 
--  event  has  been  scheduled 
pri_lst(ppl) . slct_flg:=  TRUE; 
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--  fill  the  external  table  module 

fill  ext  tab(buff_ptr,occb_ptr(j) ;cm_ptr, 

ptr_r_to_o(j )  , r.ocb_data) ;  —  r: 

--  insert  the  dwell  at  the  end  of  the  Radar 

--  Event  Control  Table  list 

llend(r , rect_ptr) ;  --  from  rsm5a.pkg 

--  load  the  evaluation  module 
--  rsmll  never  written 

--  update  the  used  resources 
IF  (pri_lst(ppl) .que_id  =  track)  THEN 
trk_sra:=  trk_sra  -  1; 

ELSE 

mssl_sra:=  mssl_sra  -  1; 

END  IF; 

tot_dwl_schd:=  tot_dwl_schd  +  1; 
sru;=  sru  +  1; 

ELSE 

--  hardware  constraints  have  not  been  satisfied 
free_rect_node ( r) ;  --  from  rsm5c.pkg 

END  IF; 

--  get  next  event  in  track  or  missile  aueue 
tp  :■=  tp.nxt; 


END  CASE; 

END  IF;  --  end  traverse  event  que  &  check  for  empty  que 
--  compute  time  elapsed 

elapsed_time(ec,rtim) ;  --  from  rsml2.pkg 

--  point  to  next  priority  in  the  list 
ppl:=  pri_lst(ppl) .nxt; 

END  LOOP;  --  end  traverse  priority  list 

IF  ((intvl_num  MOD  A_to_R.op_doct .dply_rect)  =  0)  THEN 
dump;  --  from  rsml3 

Put ("Completed  interval  :  ") ; Put ( intv l_num) ;New_Line; 

END  IF; 

--  free  memory  for  next  interval 

free_memory(pool_ptr , rect_ptr) ;  --  from  rsml4.pkg 

END  LOOP;  —  end  do  one  interval 

Close (Text) ; 

END  radar_scheduler ; 

END  rrcm; 
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--  OWNER :AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  23  Oct  86 

--  MODULE  TYPE:  local  data  structure  declarations  vers  4.0 
--  PURPOSE:  declare  Radar  Scheduler  local  data  structures 
--  NAME:  Radar  Scheduler  Local  Declarations  ...RSMO.LIB 

--  This  file  contains  all  data  structures  internal  to  the  Radar  Scheduler 
--  Process. 

pragma  arithcheck(off ) ;  pragma  debug(off'); 
pragma  enumtab(of f ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  tabl , tab2 , tab7 , tab32 , tab40 ; 

PACKAGE  rsmO  IS 

USE  tabl , tab2 , tab7 , tab32 , tab40 ; 

--beam  selection  module  CONSTANTS 

rdrint:  CONSTANT  INTEGER :=  21; 
srch  que:  CONSTANT  INTEGER :=  1; 
sr_aue‘:  CONSTANT  INTEGER:-  2; 
srch*  awls:  CONSTANT  INTEGER:-  9; 
sr_dwls :  CONSTANT  INTEGER :=  2; 
rdr_rsrcs:  CONSTANT  INTEGER :=  100; 
trk  aue:  CONSTANT  INTEGER :=  3; 
mssljaue:  CONSTANT  INTEGER.--  4; 
trk  awls:  CONSTANT  INTEGER :=  10; 
mssl_dwls :  CONSTANT  INTEGER :=  5; 

opl: INTEGER; 
intvl_num : INTEGER ; 


--Radar  Event  Control  table  node 


type  OcbData  IS  RECORD 

ocb_purp  :  INTEGER 

xmit_f lg 
face_assign 
pri_mti 
doct_blnk_gte 
cltr_blnk_gte 


mis_up  com 
mis_in3x 
xmit  freq_chnl 
rev  Treq_ chnl 


boolean 
INTEGER 
ARRAY (1 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 


.2) 


rcv_treqchnl  :  INTEGER; 
subchnl  rreq_grp :  INTEGER; 
phse_coHe  :  INTEGER 


fdbk_phsecode 
mj  r_a_mode 
b_submode 
c  submode 


INTEGER 

INTEGER 

INTEGER 

INTEGER 


freq_grp_slct  : 
dwl_strt  ctl  : 
detect_tKrslds  : 
trunc  thrslds  : 
dwl_iHx_num  : 
elev_sctr  : 

dply_azim  : 

dply_elev  : 

vid_extnt  : 

rge_trk_gte_strt 
END  RECORD ; 


boolean; 
INTEGER; 
ARRAY ( 1 . .3) 
ARRAY ( 1 . . 2 ) 
INTEGER; 
INTEGER; 
INTEGER; 
INTEGER ; 
INTEGER; 

:  INTEGER; 


OF  INTEGER; 


OF  INTEGER; 
OF  INTEGER; 
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type  RadEveConTab; 

type  RECTPtr  is  access  RadEveConTab; 
type  RadEveConTab  IS  RECORD 

srch  dwl  :  SrchDatPtr;  --  See  TAB1.LIB 


trk_Hwl 

ocb_data 

beamid 

dru 

nxt_event 

TrkDatPtr;  --  See  TAB7.LIB 

OcbData ; 
string(3) ; 

INTEGER; 

RECTPtr; 

END  RECORD; 

--end  Radar  Control  Table  node  declaration 


sp :  SearchPtr; 
tp:  TrkPtr; 
r:  RECTPtr: 
rect_ptr:  RECTPtr; 
oool_ptr :  RECTPtr,- 
buff_ptr:  PtrOccb; 
cm_pcr:  PtrRtoO; 

•-  See  TAB1.LIB 
•-  See  TAB2.LIB 

—  See  TAB40.LIB 
--  See  TAB32.LIB 

END  rsmO; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Nov  86 

--  MODULE  TYPE:  Radar  Schedular  Module  vers  4.0 

--  PURPOSE:  Initialize  lists  and  variable  for  the  Radar  Schedular  Process 
--  NAME:  Radar  Schedular  Initialization  ...RSMO.PKG 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  tabl , tab2 , tab7 , tab32 , tab40  ; 

PACKAGE  BODY  rsmO  IS 

USE  tabl , tab2 , tab7 , tab32 , tab40 ; 

--  initialization  module  constants 

pool_length:  CONSTANT  INTEGER :=  22; 
buff_pool_length:  CONSTANT :=  2; 

--  Procedure  make_pool  is  derived  from  PL1  RSM1A  module  (MAKE  POOL)  . 

--  This  procedure  creates  a  pool  of  available  Radar  Event  Control 
--  Table  nodes  (see  RSMO). 

PROCEDURE  make_pool(FirstNode : IN  OUT  RECTPtr ;numb_nodes : IN  INTEGER)  IS 
count:  INTEGER; 

P,q:  RECTPtr  :=  MEW  RadEveConTab; 

3EGIN 

p .nxt^event :=  null; 
p.srcn_dwl:=  New  SrchData; 
p.trk_dwl:=  New  TrkData; 
p:=  FirscNode; 
p.ALL:=  Firs tNode .ALL; 


FOR  count  IN  2 . .numb_nodes  LOOP 
q:=  NEW  RadEveConTab; 
q.srch  dwl:=  New  SrchData; 
q.trk_3wl:=  New  TrkData; 
q.nxt_event :=  null; 
p.nxt_event:=  q; 
p .nxt_event. ALL :=  q.ALL; 
p:=  p.nxt_event; 

END  LOOP; 

END  make_pool; 
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--  This  procedure  is  derived  from  PL1  RSM1B  (CREATE  DWELL  BUFFER  POOLS). 
--  This  procedure  creates  two  circular  lists  for  each  of  the  common 
--  memory  interfaced  data  structures  (see  TABLE32  &  TABLE40)  which 
--  receive  the  formatted  dwells  from  the  Radar  Scheduler  Process. 


PROCEDURE  ex_buff_create (buffi :IN  OUT  OCCBPtrArray ;buff2 :IN  OUT  ROPtrArray? 

length:  IN  INTEGER)  IS 


pi  ,ql  :PtrOccb  -.=  NEW  OccbType; 
p2,q2:PtrRtoO  :=  NEW  RtoO; 
ctr , j :  INTEGER; 

3EGIN 

FOR  j  IN  1 . . 2  LOOP 
pi  :=  buffi (j ) ; 
pl.link.-=  null? 


FOR  ctr  IN  1 . . lenath  LOOP 
ql:=  NEW  OccbType; 
ql.link:=  null; 
pi. link :=  ql ; 

q2:=  NEW  RtoO; 
q2.1ink:-  null; 
p2.1ink:=  a2; 

END  ‘LOOP ; 

--  create  circular  lists 

ql.link.-=  buffi  (i); 
a2.1ink:=  buff2(j); 

END  LOOP? 

END  ex_buff_create ; 
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BEGIN 

pool_ptr:=  NEW  RadEveConTab; 
pool_ptr.nxt  event :=  null; 
pool_ptr . srcK  dwl:=  NEW  SrchData; 
pool_ptr . trk_3wl :=  NEW  TrkData; 
make_pool(pool_ptr ,  pool_length) ; 
buff_ptr:=  NEW  OccbType; 
buff_ptr . link :=  null; 
cm_ptr:=  NEW  RtoO; 
cm_ptr . link :=  null; 

ex3uff_c reate  (occb_ptr  ,ptr_r_to_o  (buff_pool_length) ; 

sp:=  NEW  SearchNode; 
sp.info:=  NEW  SrchData; 

3D.nXt:=  null; 

tb:  =  NEW  TrackNode; 

cb. info.p_trk.-=  NEW  TrkFile: 

tp. info.p_trk.beam_daca :=  NEW  TrkData ; 

tp.nxt:=  null; 

r':=  NEW  RadEveConTab; 

r.srch  dwl:=  NEW  SrchData; 

r . trk_3wl :=NEW  TrkData; 

r.nxt_event:=  null; 

rect_ptr:=  NEW  RadEveConTab; 

receipt*" •  srch^awl :■=  MEW  SrchData; 

rect_ptr . trk_3wl :=  NEW  TrkData; 

recc_ptr .nxt_event null; 


END  rsmO ; 


--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  internal  routine  for  the  Radar  Scheduler  vers  2.0 
--  PURPOSE:  swap  output  buffers  for  the  next  scheduling  intervial 
--  NAME:  SWAP...  RSM2.LIB 

--  This  module  maintains  the  pointers  to  the  two  non-current  dwell  buffers 
--  which  are  the  destination  of  the  formated  dwells  scheduled  during  the 
--  current  scheduling  intervial. 

pragma  arithcheckfof f ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangechecx(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on) ; 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  tab32,tab40; 

PACKAGE  rsm2  IS 

USE  tab32,tab40; 

PROCEDURE  swap (buff: IN  OUT  PtrOccb ; cm : IN  OUT  PtrRtoO ; index : IN  OUT  INTEGER); 
END  rsm2 ; 


110 


—  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

—  MODULE  TYPE:  internal  routine  for  the  Radar  Scheduler  vers  2.0 
--  PURPOSE:  swap  output  buffers  for  the  next  scheduling  intervial 
--  NAME:  SWAP...  RSM2.PKG 

--  This  module  maintains  the  pointers  to  the  two  non-current  dwell  buffers 

—  which  are  the  destination  of  the  formated  dwells  scheduled  during  the 
--  current  scheduling  intervial. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off) ;  pragma  rangecheck(of f ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  tab32,tab40; 

PACKAGE  BODY  rsm2  IS 

USE  tab32,tab40; 

PROCEDURE  swap (buff: IN  OUT  PtrOccb;cm:IN  OUT  PtrRtoO ; index : IN  OUT  INTEGER) 
IS 


BEGIN 

IF  (index=2)  THEN 
index:-  I; 

ELSE 

index:-  2; 

END  IF; 

buff : =  occb_ptr (index) ; 
cm:=  ptr_r_to_o( index) ; 

END  swap; 

END  rsm2; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  Radar  Scheduler  Module  vers  3.0 

--  PURPOSE:  enhance  and  dehance  priorities  of  events  in  the  Radar  Event 
--  Priority  List 
—  NAME:  enhance...  RSM3.LIB 

--  This  module  enhances  the  priorities  of  the  radar  events  as  listed  in 
--  the  Priority  List  if  certian  conditions  are  met.  The  conditions  are: 

1.  The  enhance  flag  must  be  set  to  true 

2.  The  ltx  value  must  be  greater  than  the  allwd_ltx  value 

pragma  arithcheckfoff ) ;  pragma  debug(off); 
pragma  enumtab(off)  pragma  rangecheck(off )  ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab<,on) ;  pragma  rangecheck(on)  ; 

PACKAGE  rsm3  IS 

PROCEDURE  enhance(elapsed_time:  IN  INTEGER); 

END  rsm3 ; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 

—  MODULE  TYPE:  Radar  Scheduler  Module  vers  3.0 

--  PURPOSE:  enhance  and  dehance  priorities  of  events  in  the  Radar  Event 

—  Priority  List 

--  NAME:  enhance...  RSM3.PKG 

pragma  arithcheck^off ) ;  pragma  debug(off) ; 

fc(off); 

on) ; 

WITH  tabO; 

PACKAGE  30DY  rsm3  IS 
USE  tabO; 


pragma  enumtaD^orr ; ;  pragma  rangecnec. 
@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangechecfe( 


--  OWNER:  AEGIS  Modeling  GrouD 

--  DATE  OF  LAST  UPDATE:  26  Nov  86 

--  MODULE  TYPE:  Radar  Scheduler  Subroutine 

--  PURPOSE:  remove,  insert  and  reset  the  current  oriorities  of  Priority 
--  List  Events 

--  NAME:  Remove  and  Insert  ...  RSM3A 


--  This  module  locates  a  request  event  node  in  the  priority  list, 

--  removes  it  from  its  current  priority,  then  locates  _ts  hew  position 
--  in  the  priority  list,  and  inserts  it  there. 

PROCEDURE  ripl(curnt,  new_p:  IN  INTEGER)  IS 

P:  INTEGER :=  1; 
b4:  INTEGER :=  1: 
tempi,  tempi:  INTEGER; 


BEGIN 

IF  (curnt  /=  new j)  THEN 

--  remove  the  node  from  its  current  position 
WHILE  (pri_lst(p) .c_pri  /=  curnt)  LOOP 
b4:=  p(- 

p:=  pn_lst(p)  .nxt; 

END  LOOP; 
tempi :=  D ; 

pri_lst(b4)  .nxt:=  pri_lst(templ)  .nxt; 
pri_ls t( tempi) .nxt :=  0; 

--  insert  the  node  at  the  new  priority 
b4j=  1; 

$HILE  (pri_lst(p) .c_pri  /=  new_p)  LOOP 
b4:=  p(- 

p.-=  pn_lst(p)  .nxt; 

END  LOOP; 


temp2 :=p; 

pri_lst(b4) .nxt:=  tempi; 
pri_lst(templ) .nxt:=  temp2; 


—  reset  all  current  priority  values 
tempi :=  0; 

$HILE'(p  /=  0)  LOOP 
tempi :=  tempi  +  1; 

pri_-,-w_x  - ,  _ 

P :=  . 

END  LOOP; 

END  IF; 


>ri_ist(p) . c_pri :=  tempi; 
;:=  pri_lst(p) .nxt; 


END  ripl; 
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—  This  module  enhances  the  priorities  of  the  radar  events  as  listed  in 

—  the  Priority  List  if  certian  conditions  are  met.  The  conditions  ares 

1.  The  enhance  flag  must  be  set  to  true 

2.  The  ltx  value  must  be  greater  than  the  allwd_ltx  value 


PROCEDURE  enhance (elapsed_time :  IN  INTEGER)  IS 

p:  INTEGER :=  1; 
new_pri:  INTEGER; 

BEGIN 

--  reset  the  value  of  ltx  for  all  events 

NHILE  (pri  lst(p) .nxt  /=  0)  LOOP 
IF  pri^lst(p)  . slct_£la  THEN 
Drf_iSt(p)  .  ltX:  =  O'; 
pri_lst(p) .sict_flg:=  false; 

ELSE 

pri_lst(p) . ltx :=  pri_lst(p) . ltx  +  elapsed  time; 

END  IF; 

p-.=  pri  lst(p).nxt; 

END  LOOP; 

--  traverse  the  priority  list 

FOR  p  IN  Io_ennnc . .max_pri  LOOP 

--  look  only  for  events  which  can  be  enhanced 

IF  ( (pri_lst(p;  .a.nhnc)  AND  (pri_lst(p) .  status) )  THEN 

--  is  elapsed  time  more  than  allowed  time? 

IF  (pri_lsf(p) . ltx  >  pn_lst(p)  .allwd_ltx)  THEN 

--  current  priority  is  above  standard  enhancement  value 
--  but  below  the  lowest  enhancement  value 

IF  ((pri  lst(p).c_pri  <=  (pri_lst(p) .b_pri  -  4))  AND 
(pri_Ilst(p)  .c_pri  >  lo_enhnc))  THEN 

new_pri:=  pri_lst(p) . c_pri  -  1; 

ELSE 

new  nri:=  pri_lst(p) .b _pri  -  4; 

—  3o  not  enhance  past  the  lowest  enhancement  value 
IF  (new_pri  <  lo_enhnc)  THEN 
new_pri:=  lo_enhnc; 

END  IF; 

END  IF; 

--  insert  the  event  at  its  new  priority  in  the  Radar  Event 
--  Priority  List 

ripl(pri_lst(p) .c_pri,  new_pri);  —  from  rsm3a 
END  IF; 

END  IF; 

END  LOOP; 

END  enhance; 

END  rsm3; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  8  Dec  86 

--  MODULE  TYPE:  Radar  Scheduler  Subroutines 

--  PRUPOSE :  Support  the  Beam  Selection  process 

--  NAME:  Beam  Selection  Routines...  RSM5.LIB  vers  2.0 

--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Aug  86 
--  MODULE  TYPE:  Radar  Scheduler  Subroutine 
--  PRUPOSE:  insert  a  node  at  the  end  of  a  linked  list 
--  NAME:  llend  ...  RSM5A 

--  This  subroutine  has  two  input  parameters:  Mq"  is  a  pointer  to  the 
--  node  which  is  to  be  inserted,  "s"  is  a  pointer  to  the  list  to  which 
--  the  node  is  to  be  inserted  at  the  end  o‘f. 

--  OWNER:  AEGIS  Modeling  GrouD 

--  DATE  OF  LAST  UPDATE:  30  Aug  36 

--  MODULE  TYPE:  Beam  selection  subroutine 

--  PURPOSE:  assign  a  Radar  Event  Control  Node  from  a  pool  of  available 
--  nodes 

--  NAME:  Get  Rect  Node  ...  RSM5B 

--  This  module  locates  the  first  available  RECT  node  from  the  pool.  It 
--  removes  the  node  from  the  pool  and  passes  its  pointer  back  to  the 
--  invoking  procedure. 

--  OWNER:  AEGIS  Modeling  GrouD 

--  DATE  OF  LAST  UPDATE:  30  Aug  36 

--  MODULE  TYPE:  Beam  Selection  subroutine 

--  PURPOSE:  return  an  unused  RECT  node  to  the  available  pool  of  nodes 
--  NAME:  Free  RECT  node  ...  ESUEC 

--  This  module  returns  an  unused  radar  eeve.ot  control  node  to  the 
--  available  pool  of  radar  event  control  nodes. 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 
pragma  enumtab(off ) ;  pragma  rangechecK(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

<f  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  rsmO; 

PACKAGE  rsm5  IS 

USE  rsmO ; 

PROCEDURE  llend(q,s:  IN  OUT  RECTPtr); 

FUNCTION  get_rect_node  RETURN  RECTPtr; 

PROCEDURE  free_rect_node(p:  IN  OUT  RECTPtr); 

END  rsm5; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  8  Dec  86 

--  MODULE  TYPE:  Radar  Scheduler  Subroutines  vers  2.0 
—  PRUPOSE :  Support  the  Beam  Selection  process 
--  NAME:  Beam  Selection  Routines...  RSM5.PKG 


pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangechecx(of f ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  tabl , tab7 , rsmO ; 

PACKAGE  BODY  rsm5  IS 

USE  tabl , tab7 , rsmO ? 

--  oointers  for  procedure/function  use  only 
p:  RECTPtr; 

--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Aug  86 
--  MODULE  TYPE:  Radar  Scheduler  Subroutine 
—  PRUPOSE :  insert  a  node  at  the  end  of  a  linked  list 
--  NAME:  liend  ...  RSM5A 

--  This  subroutine  has  two  input  parameters:  "q"  is  a  pointer  to  che 
--  node  which  is  to  be  inserted,  's'1  is  a  pointer  to  "the  list  to  which 
--  the  node  is  to  be  inserted  at  the  end  of. 

PROCEDURE  llend(q,s:  IN  OUT  RECTPtr )  IS 

3EGIN 

—  set  the  new  node's  pointer  to  null 
q.nxt_event :=  null; 

--  check  for  an  empty  list 
IF  (s  =  null)  THEN 
S:=  q; 

ELSE 

^HILE ' (p . nxt_event  /=  null)  LOOP 
p : =  p.nxt_event; 

END  LOOP; 

--  insert  the  new  node  at  the  end  of  the  list 
p.nxt_event:=  q; 

END  IF; 

END  liend; 
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OWNER:  AEGIS  Modeling  Group 

DATE  OF  LAST  UPDATE:  26  Nov  86 

MODULE  TYPE:  Beam  selection  subroutine 

PURPOSE:  assign  a  Radar  Event  Control  Node  from  a  pool  of  available 
nodes 

NAME:  Get  Rect  Node  ...  RSM5B 

This  module  locates  the  first  available  RECT  node  from  the  pool.  It 
removes  the  node  from  the  pool  and  passes  its  pointer  back  to  the 
invoking  procedure. 


FUNCTION  get_rect_node  RETURN  RECTPtr  IS 
BEGIN 

IF  (pooljptr  =  null)  THEN 

pool_ptr:=  NEW  RadEveConTab ; 
pooijptr.srch^dwi:^  NEW  SrchData; 
pooi_pcr. crk_awl:-  NEW  TrkData; 

END  IF; 

—  set  p  to  oool_ptr  then  relink  the  list 
p:=  pooljptr; 

boo l'_p tr :  -  oooi_p tr .  nxc_event  ; 
p.nxt"  event':-  null; 

"RETURN  p; 

END  get_rect_noae ; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  2  Dec  86 

--  MODULE  TYPE:  Beam  Selection  subroutine 

--  PURPOSE:  return  an  unused  RECT  node  to  the  available  pool  of  nodes 
--  NAME:  Free  RECT  node  ...  RSM5C 

--  This  module  returns  an  unused  radar  event  control  node  to  the 
--  available  pool  of  radar  event  control  nodes. 


PROCEDURE  free_rect_node(q:  IN  OUT  RECTPtr )  IS 
BEGIN 

--  set  link  to  null 
q.nxt_avent :=  null; 

--  insert  the  node  at  the  and  of  the  node  pool  list 
IF  (pool_ptr  -  null)  THEN 
cool  otr:=  d; 

ELSc  ~ 

p:=  DOol_ptr; 

WHILE  (p.nxt_event  /=  null)  LOOP 
d:=  p.nxt_event; 

END  ‘LOOP; 

--  insert  unused  node 
c .nxt_avent :=  d; 

SND  "IF; 


END  free_rect_noae ; 
BEGIN 


--  initialise  oointer  one  time  to  avoid  reinitialzation  every 
--  time  orocecure/ function  is  called, 
p : —  MEW  RaaEveConTab r 

END  rsm5; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 

—  MODULE  TYPE:  internal  radar  scheduler  routine  vers  2.0 
--  PURPOSE:  ensure  dwells  satisfy  the  hardware  constraints 
--  NAME:  hw_constraint  ...  RSM9.LIB 

--  For  test  purposes  this  routine  assigns  a  fixed  percentage  of 
--  the  Radar  Resources  available  to  the  current  beam  being  formatted. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangechecfc(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  tabO; 

PACKAGE  rsm9  IS 

USE  tabO;  . 

PROCEDURE  'nw_constraint(id:IN  QueTvpe;  rru,dru:IN  OUT  INTEGER; 

hwc :O0T  BOOLEAN); 


END  rsm9 ; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  internal  radar  scheduler  routine  vers  2.0 
--  PURPOSE:  ensure  dwells  satisfy  the  hardware  constraints 
--  NAME:  hw_constraint  ...  RSM9.PKG 

--  For  test  purposes  this  routine  assigns  a  fixed  percentage  of 
--  the  Radar  Resources  available  to  the  current  beam  being  formatted. 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 
pragma  enumtab(off ) ;  pragma  rangechecfc(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  tabO; 

PACKAGE  BODY  rsm9  IS 
USE  tabO; 

PROCEDURE  hw_constraint(id:IN  QueType;  rru,dru:IN  OUT  INTEGER; 

hwc : OUT  BOOLEAN)  IS 

srch_pcnt:  CONSTANT  INTEGER :=  3; 
sr_pcnt :  CONSTANT  INTEGER :=  6; 
trk  ocnt:  CONSTANT  INTEGER :=  7; 
mssFjicnt:  CONSTANT  INTEGER :=  7; 

percent:  INTEGER; 


BEGIN 

--  determine  correct  percent  of  resource  for  type  queue 
CASE  id  IS 

WHEN  search  =>  percents  srchjpcnt; 

WHEN  3oecial_reouest  =>  percents  srjpcnt; 

WHEN  tiracx  =>  pe‘rcent.-=  trk_pcnt; 

WHEN  missile  =>  percents  mssl_pcnt; 

END  CASE; 

rru:=  rru  +  percent; 

--  are  the  hardware  constraints  satisfied  ? 

IF  (rru  <  100)  THEN 
dru:=  100  -  rru; 
hwc :=  true; 

ELSE 

rru:=  rru  -  percent; 
hwc :=  false; 

END  IF; 

END  hw_constraint  ; 

END  rsm9 ; 
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—  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  internal  radar  scheduler  routine  vers  2.0 

—  PURPOSE:  output  selected  and  formatted  dwells 

—  NAME:  fill  external  tables  ...  RSM10.LIB 

—  This  module  fills  the  two  common  memory  interface  dwell  buffers 

—  with  the  data  on  the  formatted  dwells.  The  buffers  are  double 

--  buffered  circularly  linked  lists.  Each  time  this  module  is  executed 
--  the  pointers  are  advanced  to  the  next  node  in  the  list. 

pragma  arithcheck(off) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangechecfc(cf f ) ; 

@  dragma  ariihcheck(on) ;  pragma  debua*(cn)  ; 

@  pragma  enumcab(,on)  pragma  rangecneck(on)  ; 

WITH  iab32 , tab40 , rsmO ; 

PACKAGE  rsmlO  IS 

USE  tab32 , tab40 , rsmO ; 

PROCEDURE  fili_ext_tabtpl ,p2:IN  OUT  PtrOccb :?3 . p4 : IN  OUT  PtrRtoO; 

or: IN  QcbDaca); 


END  rsmiO; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  internal  radar  scheduler  routine  vers  2.0 
--  PURPOSE:  output  selected  and  formatted  dwells 
—  NAME:  fill  external  tables  ...  RSM10.PKG 

--  This  module  fills  the  two  common  memory  interface  dwell  buffers 
--  with  the  data  on  the  formatted  dwells.  The  buffers  are  double 
--  buffered  circularly  linked  lists.  Each  time  this  module  is  executed 
--  the  pointers  are  advanced  to  the  next  node  in  the  list. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangechecfe(off ) ; 

0  pragma  arithcheck(on) ;  pragma  debug(on) ? 

0  pragma  enumtab(on) ;  pragma  rangecheck(on) ; 

WITH  tab32 , tab40 , rsmO ; 

PACKAGE  30DY  rsmlO  IS 

USE  tabo2 , cab40 , rsmO ; 

PROCEDURE  fill_ext_tab(pl ,p2 : IN  OUT  PtrOccb : o3 , p4 :  IN  OUT  PtrRtoO; 

or: IN  OcbData)  IS 


3EGIN 

IF  ((pi  /•-  p2)  AND  (p3  /=  ?4 ) )  THEN 
pi:-  pi. link; 
b3 ; —  b3.1ink; 

END  IF; 


--  fill  channel  buffer  structure 

pi  .  oa . cntrl  jv-ord.  rdr_xmsn_on:-  pr..:mit_clg; 

pi .ora. face pr . face~assign ; 

pi  .  oh.pni_mti :-  pr  .pn_mti(  1)  ; 

pi .oh.pri2_mti:=  pr.pri_mti(2); 

pi . ot (1 ) . otlsb :=  pr.mis_up  com; 

pi .ot(l) .otmsb:=  pr .mis^inHx; 

pl.ol.xmit  freq:=  pr.xmlt_freachnl; 

pi . ol . rcv_Treq:=  pr . rcv_f req_cEnl ; 

pi .oj . subchnl_freq_group :=  pr.subchnl_freq_grp; 

pi . o_f .phsel_code :=  pr .phse_code ; 

pi . og. fdbkl :=  pr . fdbk_phsecode ; 

pi .oa . cntrl_word. freq_group_slct :=  pr . f reqarp_slct ; 

pi . oi . dwl_l_start_time :=  pr. detect  thrslds(l); 

pi .ob.detectl_thrsld:=  pr .detect_tHrslds(l) ; 

pi .ob.detect2_thrsld:=  pr.detect_thrslds(2 ) ; 

pi .ob.detect3_thrsld:=  pr. detect  thrslds(3); 

pi .oe.truncl_thrsld:=  pr.trunc_tHrslds(l ) ; 

pi . oe . trunc2_thrsld:=  pr . trunc_thrslds (2) ; 

pi . oq. elev_sector :=  pr . elev_sctr ; 

pl.os.dply_azim:=  pr . dply_azim; 

pi .o_r .dply_elev:=  pr .dply_elev; 

pi . os .video_extnt :=  pr . rge_trk_gte_strt ; 

--  fill  R_to_0  Table  structure 

p3.dwl_data.mode :=  pr .mjr_a_mode; 

p3 .dwl_data. face :=  pr . face_assign; 

p3.dwl_data.sub_mode(l) :=  pr.b_submode; 

p3 .dwl_data. sub_mode(2) :=  pr.c  submode; 

p3 . dwl_data . dwl_idx :=  pr.dwl_i3x  num; 

p3 .dwl_data .beamourpose :=  pr .ocE  ourp; 

p3 . dwl_data . dwl_itar t_idx : =  pr . dwT_strt_ctl; 

p3.dwl_data.doct_unblnk  gates :=  pr.doct  blnk  gte; 

p3 .dwl_data. clutter_unblnk_gates :=  pr .cltr_blnk_gte ; 
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END  fill_ext_tab; 
END  rsmlO; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  21  Aug  86 

--  MODULE  TYPE:  internal  Radar  Scheduler  routine  vers  2.0 
--  PURPOSE:  compute  scheduling  interval  elapsed  time 
--  NAME:  Elapsed  Time  ...  RSM12.LIB 

--  This  module  is  designed  to  compute  the  amount  of  time  the  Radar 
--  Scheduler  has  spent  selecting  a  beam  from  the  current  requested 
--  event  queue.  The  routine  swaps  the  old  real  time  value  for  the 
--  current  real  time  value  (in  milliseconds)  and  then  computes  the 
--  new  value  of  the  real  time  and  updates  the  elapsed  time. 

pragma  arithcheck(off) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangechecfe(of f ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

§  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  rsml2  IS 

PROCEDURE  elapsed_time(et, rtim:  IN  OUT  INTEGER); 

END  rsml2; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  21  Aug  86 

--  MODULE  TYPE:  internal  Radar  Scheduler  routine 

--  PURPOSE:  compute  scheduling  interval  elapsed  time  vers  2.0 

--  NAME:  Elapsed  Time  ...  RSM12.PKG 

--  This  module  is  designed  to  compute  the  amount  of  time  the  Radar 
--  Scheduler  has  spent  selecting  a  beam  from  the  current  requested 
--  event  queue.  The  routine  swaps  the  old  real  time  value  for  the 
--  current  real  time  value  (in  milliseconds)  and  then  computes  the 
--  new  value  of  the  real  time  and  updates  the  elapsed  time. 

pragma  arithcheck(of f ) ;  pragma  debug(off); 
pragma  enumtab)  off ) pragma  rangecheck(off )  ; 

@  p'ragma  arithcheck(on) ;  pragma  debua(on); 

3  pragma  anumcab (.on) ;  pragma  rangschecic(on) ; 

WITH  global; 

PACKAGE  BODY  rsml2  IS 

USE  global; 

PROCEDURE  elapsed_uime(et , rtim:  IN  OUT  INTEGER)  IS 
oltim:  INTEGER; 


BEGIN 

oltim  :=  mm: 

rtim:-  ciock();  --  clock  from  csr7  in  global 

ac:=  ac  -r  rcim  -  oltim; 

END  elapsed_cime ; 

END  rsmlE; 
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—  OWNER:  AEGIS  MODELLING  GROUP 

—  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  Internal  Radar  Scheduler  routine  vers  2.0 
--  PURPOSE:  Print  out  the  results  of  the  latest  scheduling  interval 
for  analysis 

—  NAME:  Dump  ...  RSM13 . LIB 

--  This  routine  prints  out  the  information  on  the  radar  request  queues 
and  the  scheduled  dwells  for  the  current  interval.  The  information 
printed  consists  of: 

1.  Requested  Beam  Listing 

a.  The  name  of  the  Event  whose  queue  is  being  printed 

b.  The  identification  code  of  the  requested  beam 

c.  The  requested  beam's  position  within  the  queue 

2.  Scheduled  Dwell  Listing 

a.  The  scheduled  dwell 1  s  unique  identification  coae 

b.  The  amount  of  Radar  Resources  remaining  after  the 
scheduling  of  the  dwell  -  expressed  as  a  percentage 

c.  The  index  into  the  current  interval’s  Radar  Event' 

Control  Table 

pragma  arithcheckioff) ;  pragma  deouq(off) 
pragma  enumtab (  off ) oraqma  rangecheck(off)  ; 
p'ragma  arithcneck( on) ;  oraqma  deoug(on); 
pragma  enumtatMon);  pragma  rangecheck(on) ; 


WITH  Io; 

PACKAGE  rsrnlc  2S 


USE  lo; 

Text:  File; 

PROCEDURE  lump; 

END  rsm!3; 
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--  OWNER:  AEGIS  MODELLING  GROUP 
--  DATE  OF  LAST  UPDATE:  26  Nov  86 

--  MODULE  TYPE:  Internal  Radar  Scheduler  routine  vers  2.0 
--  PURPOSE:  Print  out  the  results  of  the  latest  scheduling  interval 
for  analysis 

--  NAME:  Dump  ...  RSM13.PKG 

--  This  routine  prints  out  the  information  on  the  radar  request  queues 
--  and  the  scheduled  dwells  for  the  current  interval.  The  information 
--  printed  consists  of: 

1.  Requested  Beam  Listing 

a.  The  name  of  the  Event  whose  queue  is  being  printed 

b.  The  identification  code  of  the  requested  beam 

c.  The  requested  beam's  position  within  the  queue 

2.  Scheduled  Dwell  Listing 

a.  The  scheduled  dwell 's  unique  identification  code 

b.  The  amount  of  Radar  Resources  remaining  after  the 

c.  The  index  to  the  current  interval's  Radar  Event 
Control  Table 

pragma  arithcheckf off ) ;  pragma  debug(off) 

pragma  enumcab(off ) ;  pragma  rangecheck(cff ) ; 

@  p'ragiha  arithcheckt  off ) ;  p'ragma  debug^off); 

§  pragma  enumtab(,crf )  ;  pragma  rangecheck(orf ) ; 

WITH  tabO , tabl , cab2 , rsmO , lo , Util ; 

PACKAGE  BODY  rsml3  IS 


USE  tabO , tabl , tab2 f rsmO , lo, Util ? 

dsn.-  strings 55)  - 

sDcr.-  SearchPtr; 
tptr:  TrkPtr; 

PROCEDURE  dump  IS 

Ctr:  INTEGER :=  1; 
start ,ctn,i:  INTEGER; 

BEGIN 

Put (Text , REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:  "); 
PutfText, intvl_num, 5) ;  New_Line(Text) ; 

Put(Text,dsh) ;  New_Line (Text) ; 

WHILE  (ctr  /=  0)  LOOP 

Put(Text,pri_lst(ctr) .eventnm) ;  New_Line(Text) ; 

IF  pri_lst(ctr) . status  THEN 

Put(Text , "BEAM  ID  "); 

i:=  0; 

CASE  pri_lst(ctr) . que_id  IS 

WHEN  search  |  special  request  => 

sptr:=  pri_lst(ctr) .que_ptr .Snode; 

WHILE  ((i  <  10)  AND  (sptr  /=  null))  LOOP 
i  :  =  i  +  1 ; 

Put(Text, sptr. info  .bid);  Put(Text,"  "); 
sptr:=  sptr.nxt; 

END  LOOP; 

WHEN  track  |  missile  => 

tptr:=  pri_lst(ctr) .que_ptr .Tnode; 

WHILE  ((i  <  10)  AND  (tptr  /=  null))  LOOP 
i  :=  i  +  1 ; 

Put(Text, tptr. info  .bid);  Put(Text,"  "); 
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tptr:=  tptr.nxt; 

END  LOOP; 

END  CASE; 

New  Line (Text) ; 

PutlText, "QUEUE  POSIT  "); 

FOR  ctn  IN  1. .i  LOOP 
Put(Text,ctn,4) ; 

END  LOOP; 

New  Line (Text) ; 

PutXText,dsh) ;  New_Line (Text) ; 

ELSE 

?ut(Text,"  NO  REQUESTS  THIS  INTERVAL"); 

New_Line (Text) ;  Put (Text, ash) ;  New_Line (Text) ; 

END  IF; 

ctr:=  pri_lst(ctr) .nxt; 

END  LOOP; 

New  Line(Text); 

PurTText, "SCHEDULED  DWELLS  FOR  SCHEDULER  INTERVAL:  "); 
Put (Text , intvl_num, 5 ) ;  New_LineiText); 

Put (Text, dsn) ;  New_Line(Text) ; 
rptr:=  rect_ptr,- 
start ;=  L; 


WHII 


IE  rptr  /=  null)  LOOP 
P  rstr; 

1  :  —  0"; 

Put (Text, "BEAM  ID  "); 

WHILE  ({:.  <  10)  AND  (p  /=  null))  LOOP 
1 :  =  1  +  1  ; 

Put(Text,p.beamid) ;  Put(Text,"  "); 
p  :=  p.nxt_event; 

END  LOOP; 

New  Line(Text) ; 

Put^Text, "RESOURCES  "); 
i  :=  0; 


p:=  rptr: 

WHILE  ((i  <  10)  AND  (p  /=  null))  LOOP 
i:=  i  +  1; 

Put(Text,p.dru,4) ; 
p :=  p.nxt_event; 

END  LOOP; 

New  Line(Text) ; 

Put^Text, "DWELL  #  "); 

FOR  ctn  IN  start (start  +  i  -  1)  LOOP 
Put(Text,ctn,4) ; 


END  LOOP; 

New  Line (Text) ; 

PutTText,dsh) ;  New_Line (Text) ; 
IF  (p  /=  null)  THEN 
rptr :=  P; 

start :=  start  +  i; 

ELSE 


rptr:=  null; 
END  IF; 


END  LOOP; 

Put(Text,dsh) ;  New_Line (Text) ;  New_Line(Text) ; 
END  dump; 

BEGIN 
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--  initialize  working  pointers  one  time  to  avoid  reinitialization 

--  each  time  procedure  is  invoked. 

sptr:=  NEW  SearchNode; 

tptr:=  NEW  TrackMode; 

rptr:=  NEW  RadEveConTab; 

p :=  NEW  RadEveConTab; 

END  rsml3; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  29  Aug  86 

--  MODULE  TYPE:  internal  Radar  Scheduler  routine  vers  2.0 
--  PURPOSE:  free  memory  for  the  next  scheduling  interval 
--  NAME:  Free  Memory  ...  RSM14 . LIB 

—  This  module  traverses  the  available  RECT  pool  list  and  inserts  the 
--  current  Radar  Event  Control  Table  list  at  the  end  of  the  pool. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  rsmO; 

PACKAGE  rsmi4  IS 

USE  rsmO  ; 

PROCEDURE  free_memory(pool_ptr , rect_ptr :IN  OUT  RECTPtr) ; 

END  rsm!4; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  29  Aug  86 

--  MODULE  TYPE:  internal  Radar  Scheduler  routine  vers  2.0 
--  PURPOSE:  free  memory  for  the  next  scheduling  interval 
--  NAME:  Free  Memory  ...  RSM14.PKG 

--  This  module  traverses  the  available  RECT  pool  list  and  inserts  the 
--  current  Radar  Event  Control  Table  list  at  the  end  of  the  pool. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  rsmO; 

PACKAGE  BODY  rsml4  IS 
USE  rsmO  ; 

--  pointer  for  procedure  use  only 
p:  RECTPtr ; 

PROCEDURE  free_memory(pooi_ptr , rect_ptr :IN  OUT  RECTPtr)  IS 
BEGIN 

IF  (pooi_ptr  =  null)  THEN 
pooi_ptr:=  rect_ptr; 
rect  otr:=  null; 

ELSE 

O  :=  oool  otr- 

While  (p.nxt_event  /=  null)  LOOP 
p :=  p .nxt_event ; 

END  LOOP*; 

p.nxt_event:=  recc_ptr; 
rect  otr:=  null; 

END  IF; 

END  free_memory; 

BEGIN 


--  initialize  working  pointer  one  time  to  avoid 
--  reinitialization  each  time  procedure  is  invoked. 
p:=  NEW  RadEveConTab; 

END  rsm!4; 
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APPENDIX  D 

TEST  HARNESS  SOURCE  CODE 


—  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  24  Sep  86 

—  MODULE  TYPE:  Display  Subroutine  vers  2.0 
--  PURPOSE:  Operator  Interface 

--  NAME:  Operator  Interface  Module  ...  SADM1.LIB 

--  This  module  provides  the  user  of  the  Radar  Scheduler  Test 
--  Harness  (SPY'. COM)  with  the  ability  to  alter  some  of  the 
--  major  program  carameters  prior  to' execution  of  the  program 
--  with  out  having  to  alter  the  source  code,  recompile,  and 
--  link  the  program. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangecheck(off) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on) ; 

<f  pragma  enumtab(on) ;  pragma  rangecheck(on) ; 

PACKAGE  sadml  i.S 

PROCEDURE  oim(numtrks ,numintvls , skipintvls :  OUT  INTEGER); 
END  sadml; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  24  Sep  86 
--  MODULE  TYPE:  Display  Subroutine  vers  2.0 
--  PURPOSE:  Operator  Interface 

--  NAME:  Operator  Interface  Module  ...  SADM1.PKG 

--  This  module  provides  the  user  of  the  Radar  Scheduler  Test 
--  Harness  (SPY.COM)  with  the  ability  to  alter  some  of  the 

—  major  program  parameters  prior  to* execution  of  the  program 
--  with  out  having  to  alter  t:he  source  code,  recompile,  and 

—  link  the  program. 

pragma  arithcheckf off ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangecheck(off ) ; 

@  p'ragma  anthcheck(on) ;  pragma  debug(on)  ; 

@  pragma  anumtab(on);  pragma  rangecheck(on) ; 

WITH  Util? 

PACKAGE  SODY  sadml  IS 
USE  Util; 

PROCEDURE  oimi numcrks ,numintvls , skipintvls :  OUT  INTEGER)  IS 

astrklS:  CONSTANT  STRING:-  "***************» ; 
spaceiO :  CONSTANT  STRING :=  "  " ; 

3EGIN 

Put(astrklS) ;  ?ut("  AEGIS  AN/SPY1-A  "); 

?ut(astrkl5 ) ;  New  Line; 

Put (astrklS )  ;  PutT"  RADAR  SCHEDULER  PROGRAM  11 )  ; 

?ut( astrklS ) ;  Mew_Line ? 

?ut( astrklS ) ;  Put(astrkl5 ) ;  Put; astrklS ) ;  Put(astrklS) ; 
New_Line;  Mew_Line;  lew J,ins ;  Hev;_Line; 

Put("InDUt  the  number  or  tracks  to  be  tnitialited. 11 )  ; 

New  Line;  New_Line;  Put(spaceiQ) ; 

PutX"NUMBER  OF  TRACKS  --->  ");  Get(numtrks) ;  New_Line; 
New  Line?  New_Line; 

PutX" Input  the  number  of  scheduling  intervals  to  be  run.1 
New  Line;  New_Line?  Put(spacelO) ; 

PutX"NUMBER  OF  INTERVALS  --->  " ) ;  Get(numintvls) ; 

New  Line,-  New  Line;  New  Line; 

PutX"Defme  tKe  interval  display  delay  period."); 

New  Line;  New_Line;  Put (space 10 ) ; 

PutT"SKIP  INTERVALS  --->  ’■);  Get(skipintvls) ;  New_Line; 
New  Line;  New_Line;  New_Line; 

PutTspacelO) ;  Put(spacelO) ;  Put("BEGIN  EXECUTION"); 
New_Line ; 

END  oim; 

END  sadml; 
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--  OWNER:  AEGIS  MODELING  GROUP 
--  DATE  OF  LAST  UPDATE  :  31  AUG  86 
--  MODULE  TYPE:  PROCESS  VERS  3.0 
—  PURPOSE:  MODEL  THE  RADAR  SCHEDULER  FUNCTION 
NAME:  SEARCH  MANAGEMENT  ...  SRCM.LIB 


--  The  purpose  of  this  module  is  to  manage  the 
--  request  of  search  and  special  request  radar 
--  events.  The  current  design  processes  static 
--  data  for  the  Radar  Scheduler  Test  Harness. 

pragma  arithcheck(off ) ;  pragma  aebug(off); 
pragma  enumtab(ofr ) ;  braqma  rangechecK(off ) 
@  pragma  arithcheck(on) ;  pragma  debug! on) ; 

£  pragma  enumtab(on);  pragma  rangecheck(on) 

PACKAGE  srcm  IS 

PROCEDURE  searchmgmt; 

END  srcm; 
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--  OWNER:  AEGIS  MODELING  GROUP 
--  DATE  OF  LAST  UPDATE  :  30  Sep  86 
—  MODULE  TYPE:  PROCESS  VERS  3.0 
--  PURPOSE:  MODEL  THE  RADAR  SCHEDULER  FUNCTION 
--  NAME:  SEARCH  MANAGEMENT  ...  SRCM.PKG 


--  The  purpose  of  this  module  is  to  manage  the 
--  request  of  search  and  special  request  radar 
--  events.  The  current  design  processes  static 
--  data  for  the  Radar  Scheduler  Test  Harness. 

pragma  arithcheck(of f ) ;  pragma  debug(off ) ; 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 
@  pragma  arithcheck(on) ;  pragma  debug ( on ) ; 

@  pragma  enumcao(on) ;  pragma  rangecheck(on) ; 

WITH  global, tabO , smml , smm2 ; 

PACKAGE  BODY  srcm  IS 

USE  global , tabO , smml , smm2 ; 

PROCEDURE  searchmgmt  IS 

lauad:  INTEGER: 

TYPE  SeamCounc  IS  ARRAY(1..2)  OF  INTEGER; 
’om^ctr:  3eamCount ; 
ppl,rnum,i:  INTEGER; 


3EGIN 


--  not  initialized  for  test  purposes,  taken  from  smml 
--  lauad :=  1; 

--  bm_ccr (1 )  :•=  0 ; 

--  bm_ctr(.2)  :=  0; 

sm_init;  --  from  smml.pkg 

FOR  i  IN  1.. infinity  LOOP 
await(s_pid, es_id, i) ; 

--  traverse  the  radar  event  priority  list 

($nLE  (ppl  /=  0)  LOOP 

IF  ( (prills t (ppl) • que_id  =  search)  OR 

tprr_lst(ppl) . que_id  =  special_request) )  THEN 

fill_que(pri_lst(ppl) ) ; 

END  IF; 

--  point  to  the  nest  priority  in  the  list 
ppl:=  pri_lst(ppl) .nxt; 

END  LOOP; 

END  LOOP; 

END  searchmgmt; 

END  srcm; 
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--  AEGIS  MODELING  GROUP 

--  DATE  OF  LAST  UPDATE:  31  AUG  86 

--  MODULE  TYPE:  SEARCH  MANAGEMENT  MODULE  vers  2.0 

—  PURPOSE:  INITIALIZE  THE  SEARCH  EVENT  QUEUES  IN  THE 

PRIORITY  LIST 

—  NAME:  SEARCH  MANAGEMENT  INITIALIZATION  ...  SMM1.LIB 

--  This  module  is  executed  once.  Its  purpose  is  to  allocate 
--  memory  for  search  nodes  (Table  1)  and  create  empty  request 

—  queues  for  each  search  and  special  request  radar  event  in 

—  the  Radar  Event  Priority  List  (Table  0) . 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangecheck(of f ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on) ; 

(f  pragma  enumtab(on;;  pragma  rangecheck(on)  ; 

PACKAGE  smml  IS 

PROCEDURE  sm_init; 

END  smml ; 
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--  AEGIS  MODELING  GROUP 

--  DATE  OF  LAST  UPDATE:  26  Nov  86 

--  MODULE  TYPE:  SEARCH  MANAGEMENT  MODULE  vers  2.0 
--  PURPOSE:  INITIALIZE  THE  SEARCH  EVENT  QUEUES  IN  THE 
PRIORITY  LIST 

--  NAME:  SEARCH  MANAGEMENT  INITIALIZATION  ...  SMM1.PKG 

--  This  module  is  executed  once.  Its  purpose  is  to  allocate 
--  memory  for  search  nodes  (Table  1)  and  create  empty  request 
--  queues  for  each  search  and  special  request  radar  event  in 
--  the  Radar  Event  Priority  List  (Table  0) . 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  oragma  rangecheck( of f ) ; 

@  p'ragma  arithcheck( on) ;  pragma  debugs  on ); 

<3  pragma  enumtab(,on) ;  pragma  rangecneck(on)  ; 

WITH  tabO , tabi ; 

PACKAGE  BODY  smnu  IS 

USE  tabO , tabi ; 

PROCEDURE  sm_imt  IS 

p,qptr:  SearchPtr:-  NEW  SearchNode; 
q:  “SearchPtr; 
ctr:  INTEGER:-  1; 
node_ctr:  INTEGER; 

BEGIN 


--  traverse  the  Priority  Event  List 
WHILE  (ctr  /=  0)  LOOP  * 

IF  ( (pri_Ist( err ) . que_ia  =  search)  DR 

vpri_ist(ctr) . que_id  =  special_v-equest) )  THEM 


initialize  the  queue  to  length  -  max_nodes 


p:=  pri_lst(ctr) .que_ptr.Snode; 
node_ctr:=  0; 

WHILE  (node_ctr  <  pri_lst(ctr) .max_nodes)  LOOP 
node_ctr:=  node_ctr  +  1; 
q:=  NEW  SearchNode; 
q.info:=  NEW  SrchData; 
q.nxt:=  null; 

--  insert  at  the  end  of  event  queue  p 
IF  (p  =  null)  THEN 


P 


ELS 


i 


. que_ptr .Snode := 


q; 


--  search  for  the  end  of 
qptr  :=  p; 

WHILE  (qptr.nxt  /=  null) 
qptr:=  qptr.nxt; 

END  LOOP; 

--  insert  the  new  node 
qptr.nxt:=  q; 

END  IF; 

END  LOOP; 

END  IF; 

ctr:=  pri_lst(ctr) .nxt; 

END  LOOP; 


the  event  queue 
LOOP 


END  sm_init; 


END  smml ; 
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--  OWNER:  AEGIS  MODELING  GROUP 
--  DATE  OF  LAST  UPDATE:  30  Sep  86 

--  MODULE  TYPE:  SEARCH  MANAGEMENT  SUBROUTINE  vers  2.0 
--  PURPOSE:  FILL  A  PRIORITY  LIST  SEARCH  QUEUE 
--  NAME:  FILL  SEARCH  QUEUE  . . . SMM2.LIB 

--  This  routine  is  responsible  for  filling  a  priority 
--  event  queue  with  the  proper  synchronous  beam  request 
--  data.  It  executes  the  following  functions  for  each 
--  event  in  the  priority  list  which  corresponds  to  a 
--  Search  Management  event.  The  Fill  Search  Queue 
--  subroutine  calculates;  beam  mode,  unique  beam  id, 

--  beam  position  (azimuth  and  elevation),  instrumented 
--  range,  blanking  cates,  the  end  of  frame  indicator, 

--  the  Radar  Event  Priority  List  (Table  0).--  and  requestor  identity. 

pragma  anthcheck(off ) ;  pragma  debug(orf); 
bragma  enumtaot off ) ?  praama  rangecheck(o£f ) ; 

@  pragma  anthcheck(on) ;  pragma  debug’(onj; 

(§  pragma  enumtab(on) ;  pragma  rangecheckvon)  ; 

WITH  tabO; 

PACKAGE  smm2  IS 

USE  tabO ; 

PROCEDURE  fill_que(pn_Ist :  IN  OUT  PriLstPtr)  ; 

TYPE  oeamCtrArrav  IS  ARRAY(1..2)  OF  INTEGER; 
bm_ctr:  BeamCtrArray; 

Iquad:  INTEGER; 

END  smm2 ; 
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—  OWNER:  AEGIS  MODELING  GROUP 

--  DATE  OF  LAST  UPDATE:  30  Sep  86 

—  MODULE  TYPE:  SEARCH  MANAGEMENT  SUBROUTINE  vers  2.0 
--  PURPOSE:  FILL  A  PRIORITY  LIST  SEARCH  QUEUE 

--  NAME:  FILL  SEARCH  QUEUE  ...SMM2.PKG 

--  This  routine  is  responsible  for  filling  a  priority 
--  event  queue  with  the  proper  synchronous  beam  request 
--  data.  It  executes  the  following  functions  for  each 
--  event  in  the  priority  list  which  corresponds  to  a 
--  Search  Management  event.  The  Fill  Search  Queue 
--  subroutine  calculates;  beam  mode,  unique  beam  id, 

—  beam  position  (azimuth  and  elevation),  instrumented 
--  range,  blanking  dates,  the  end  of  frame  indicator, 

--  the  Radar  Event  Priority  List  (Table  0).--  and  requestor  identity. 

pragma  arithcheck(off) ;  pragma  aebug(off); 
pragma  enumtam off ) ;  pragma  rangecheck(off ) ; 

@  p*ragma  anthcheck(cn) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  global, tabO , tabl , StrLib ; 

PACKAGE  30DY  smm2  IS 

USE  global, tabO, tabl , StrLib; 

—  OWNER:  AEGIS  Moaeiina  Grouo 
--  DATE  OF  LAST  UPDATE: 'l  Oct' 36 

--  MODULE  TYPE:  Search  Management  subroutine 

—  PURPOSE:  Calculate  beam  position 

—  NAME:  Beam  Position  ...  SHM2A 

--  This  suDroutine  calculates  the  beam  position  for  search  type 
--  beams  based  on  the  calling  parameter's  -  que  identity  and  random 

—  number,  the  last  quadrant 'from  which  the  "beam  was  requested 

--  and  a  pointer  to  the  event  node  for  which  the  beam  position  is 
--  being  calculated. 


PROCEDURE  bm_pos(qid:,  IN  QueType;rnum:  IN  INTEGER;  quad:  IN  OUT  INTEGER 

p:  IN  OUT  SearchPtr )  IS 

BEGIN 

IF  (quad  =  1)  THEN 
quad:=  3; 

ELSIF  (quad  =  2)  THEN 
quad:=  4; 

ELSIF  (quad  =  3)  THEN 
quad:=  2; 

ELSIF  (quad  =  4)  THEN 
quad:=  1; 

END  IF; 

--  the  rest  of  this  module  has  not  been  implemented  yet 

END  bm_pos; 
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OWNER:  AEGIS  Modeling  Group 

DATE  OF  LAST  UPDATE:  1  Oct  86 

MODULE  TYPE:  Search  Management  subroutine 

PURPOSE:  Calculate  end  of  frame  for  search  type  beams 

NAME:  End  Frame  ...  SMM2B 

This  subroutine  sets  the  end  of  frame  indication  flag  based  on 
its  input  parameters  -  beams  requested  and  event  identity.  An 
end  of  search  frame  is  indicated  for  the  horizon  search  event 
after  600  beams  have  been  scheduled.  An  end  of  search  frame  is 
indicated  for  the  above  horizon  search  after  3600  beams  have 
been  scheduled. 


FUNCTION  end_frm(num_bms , eid:  IN  INTEGER)  RETURN  BOOLEAN  IS 
BEGIN 

IF  ((eid  =  9)  AND  (num.bms  >=  600))  THEN 
RETURN  true; 

ELSIF  ((eid  =  22)  AND  (num_bms  >=  3600))  THEN 
RETURN  true; 

ELSE 

RETURN  false; 

END  IF; 

END  end_rrm; 
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PROCEDURE  fill_que(pri_lst:  IN  OUT  PriLstPtr)  IS 

nodes_filld:  INTEGER :=  0; 
temp:  STRING ( 10 ) ; 

aptr,p:  SearchPtr-.=  NEW  SearchNode; 
rnum:  INTEGER; 

BEGIN 


--  set  event  que  status 
rnum*.=  rand(); 

IF  ( (pri_lst .que_id  =  sDecial  request)  AND 
((rnum  MOD  max_pri)  /=  0}*)  THEN 

ori_lst. status :=  false; 

ELSE" 

ori  1st. status true; 

END'lFf 

pri_lst .quejpcr .Snode . info :=  MEW  SrcnData; 
p.info:=  MEW  SrchData,- 
qptr.info-.=  MEW  SrchData; 

--  sec  queue  pointer  to  eve.nt(trip)  pointer 
qptr:-=  pri_lst.que_ptr .Snode ; 

--  traverse  the  event  aueue  and  fill  data  fields 
O  :  —  qptr; 

WHILE*  ((p  /=  null)  AND  (pri_lst. status))  LOOP 

--  increment  the  number  of  nodes  filled  to  maintain  unique 
--  team  id.  set  mode  to  event  base  pri 
nodes _filld:=  nodss_filld  -  1; 
p .  info  ..mode  pri_lst.b_pri ; 

--  assign  uniaue  id  code  to  this  beam 

o.  info. bid Txtract{ori_.sc . aventnm , 1 , i) ;  --  from  Strlib 

temp:-  Int  to  Str (ncdes_?illd) ;  --  from  StrLib 

IF  nodes_f lllH  <  10  THEN 

temp :=  lnsert("0" , temp , 1 ) ; 

END  IF; 

p.  info. bid :=  Insert(temp,p.info.bid,2) ; 

--  calculate  beam  position  -  1)  queue  id  2)  random  #, 

--  3)  last  quadrant  entered,  4)  pointer  p 
rnum:=  rand(); 

bm_pos(pri_lst. que_id, rnum, lquad,p) ; 

--  calculate  the  instrumented  range 
--  calculate  blanking  gates 
--  not  implemented  in  this  version 

--  calculate  end  of  frame 
IF  (pri  1st. que  id  =  search)  THEN 

IF  (pri_lst."*b_pri  =  9)  THEN  --  horizon  search  frame 
bm^ctr(l):=  bm^.ctr(l)  +  1; 
p.Tnfo.eof_indTc :=  end_frm(bm  ctr(l),9); 

ELSE  --  above  horizon  search  "frame 
bm^.ctr(2):=  bm^.ctr(2)  +  1; 
p. info .eof_ind!c :=  end_f rm(bm_ctr (2) , 22 ) ; 

END  IF; 

ELSE  --  is  a  special  request  event 

p . info.eof_indic :=  false; 

END  IF; 

--  assign  requestor  id.  for  this  version  the  requestor  id 
--  is  assigned  the  value  of  the  beam  mode, 
p. info. req_id:=  p. info. mode; 

--  point  to  the  next  node  in  the  event  queue 


141 


p:=  p.nxt; 

END  LOOP; 

END  fill_que ; 

END  smm2; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  29  Sep  86 

--  MODULE  TYPE:  Process  vers  3.0 

--  PURPOSE:  Model  the  Radar  Scheduler  function 

--  NAME:  Detection  Processing  ...  DRCM.LIB 

—  This  process  models  the  Detection  Processing  process  for  the 
--  purpose  of  modeling  its  interface  to  the  Radar  Scheduler  process. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  dr cm  IS 

PROCEDURE  detectprcc; 

END  drcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  2  Dec  86 

--  MODULE  TYPE:  Process  vers  3.0 

--  PURPOSE:  Model  the  Radar  Scheduler  function 

--  NAME:  Detection  Processing  ...  DRCM.PKG 

--  This  process  models  the  Detection  Processing  process  for  the 
—  purpose  of  modeling  its  interface  to  the  Radar  Scheduler  process. 

pragma  arithcheck(off ) ;  pragma  debug(off 1 ; 
pragma  enumtab(of f ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on) ; 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  global, tab7 ,dpml ; 

PACKAGE  BODY  drcm  IS 

USE  global , tab7 , dpml ; 

PROCEDURE  detectproc  IS 

ctr , i :  INTEGER; 

BEGIN 

--  initialise  the  Track  File 
trkfilinit(ptrk) ;  --  See  DPM1.PKG 

FOR  i  IN  1.. infinity  LOOP 
await(d_pid, ea_id, i) ; 

FOR  ctr  IN  I..I26  LOOP 
null ; 

END  LOOP; 

IND  LOOP; 

END  detectproc; 

END  drcm; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  1  Oct  86 

--  MODULE  TYPE:  Detection  Processing  routine  vers  2-0 

--  PURPOSE:  Initialize  the  Track  File 

--  NAME:  Track  File  Initialization  ...  DPMI. LIB 

—  This  module  creates  the  Track  File  (table  7)  used  by  the  test 
--  harness  to  provide  the  Radar  Scheduler  with  viable  track  data. 
--  This  subroutine  invokes  the  common  service  routine  -  rand  and 
--  the  Detection  Processing  subroutine  dpinend. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(ofr) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtao(on);  pragma  rangecheck(on) ; 

WITH  tab?; 

PACKAGE  dpml  IS 

USE  tab7  ; 

PROCEDURE  trkfilinit(ptrk;OUT  PtrTrkFils); 

END  dpmi ; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  2  Dec  86 

--  MODULE  TYPE:  Detection  Processing  routine  vers  2.0 

--  PURPOSE:  Initialize  the  Track  File 

--  NAME:  Track  File  Initialization  ...  DPM1.PKG 

--  This  module  creates  the  Track  File  (table  7)  used  by  the  test 
--  harness  to  provide  the  Radar  Scheduler  with  viable  track  data. 
--  This  subroutine  invokes  the  common  service  routine  -  rand  and 
the  Detection  Processing  subroutine  dpinend. 

pragma  arithcheck(off ) ;  pragma  debug(off) ; 
pragma  enumtab(of f ) ;  pragma  rangechecfc(of f )  ; 
pragma  arithcheck(on) ;  pragma  debug(on);^ 
pragma  enumtab(on);  pragma  rangecneck(on) ; 

WITH  global , tab4 , taD? , apmia , Longops ; 

PACKAGE  30DY  dpml  IS 

USE  global, tab4 , iab7 , dpmla , Longops ; 

PROCEDURE  trkfiiinit(ptrk:  OUT  PtrTrkFile)  IS 

o>:  PtrTrkFile; 

1,1, rnum : INTEGER : 


3EGIN 

otrk:=null; 

?OR  i  IN  i . . A_to_R.op_doct.mtrks  LOOP 


--  create  a  Traci:  File  node 
p:=  MEW  TrkFile; 
b .beam_ aata NEW  TrkData; 

--  initialize  the  beam  data  based  on  a  ranaum  numoer 
rnum:=  rana(); 

--  compute  the  mode  and  priority 
j :=  ( rnum  MOD  22) ; 

IF  (((j  >=  4)  AND  (j  <=  8))  OR  ((j  >=  14)  AND  (j  <=  21)))  THEN 
p .beam_data .mode :=  j; 

ELSE 

p.beam_data.mode :=  j  +  5; 

END  IF; 

p.beam_data .priority :=  p .beam_data.mode ; 

--  these  flags  are  constant  valued 
p.beam_data.xmit_reqflg:=  true; 
p.beam_data.sim_tgt_?lg:=  false; 

--  compute  log  amplitude  estimate  of  echo  signal 
p.beam_data.log_ampld_est:=  (rnum  MOD  100); 

--  compute  "z"  position 

p.beam  data .posit . z :=  (rnum  MOD  1000); 

IF  (p.Eeam_data. posit. z  <  1000)  THEN 

p .beam_data . low_elev_trk_f lg :=  true ; 

ELSE 

p .beam_data . low_elev_trk_f lg :=  false ; 

END  IF; 

--  compute  "x"  and  "y"  positions 
IF  ((rnum  MOD  2)  =  0)  THEN 

p.beam_data. posit. x:=  rnum; 
rnum:=  rand(); 

p.beam_data. posit. y:=  0  -  rnum; 

ELSE 

p.beam_data. posit. y:=  rnum; 
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rnum:=  rand(); 

p.beam_data .posit. x:=  0  -  rnum; 

END  IF; 

--  compute  slant  range 

p .be amldata .posit . sin t_rnge :=  Labs (Lmul (Lint (p .beam_data .posit. x) , 

Lint(p.beam_data .posit .y) ) ) ; 

--  compute  velocity  vectors 

p.beam_data. posit. x_dot:=  (p.beam_data .posit .x  MOD  (-200}); 
p.beam_data. posit. y_dot:=  (p.beam_data .posit. y  MOD  (-200)); 
p.beam_data. posit. z_dot:=  (p.beam_data .posit. z  MOD  (-10)); 
p. beam_data. posit. rge  dot:= 

L_to_int(Lmod(p.Seam_data .posit. slnt_rnce , Lint (-100) ) ) ; 

--  compute  cross  gate  bin  number 
p .beamldata .xgte_5in_num :=  (rnum  MOD  1000); 

—  assian  track  numbers 
p.beam_data.ctl  grp_trk_num :=  i; 
p.beam_data.ctsl:=  I  +  100; 

--  comDUte  track  transition  flag 
IF  (i  <  5)  THEN 

o.beam_data.  trk  xsitn_flag.--  true; 

ELSE 

o.beam  data. trk_xsitn_f lag: =  false; 

END  'I? ; 

--  insert  the  track  node  at  the  end  of  the  Track  File 
dpinend(p.ptrk) ;  --  from  dpmia.pkg 

END  LOOP; 


END  trkfiiinit; 


END  dpml ; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  1  Oct  86 

—  MODULE  TYPE:  Detection  Processing  subroutine  vers  2.0 
--  PURPOSE:  Insert  a  node  at  the  end  of  a  linked  list 

--  NAME:  dpinend  ...  DPM1A.LIB 

—  This  subroutine  has  two  parameters:  new_node  is  a  pointer  to  the 
--  node  which  is  to  be  inserted,  list  head  is  a  pointer  to  the  list 
--  to  which  the  node  is  to  be  inserteH  at  the  end  of. 

pragma  arithcheck(of f ) ;  pragma  debug(off); 
pragma  enumtab(off) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  tab7; 

PACKAGE  dpmla  IS 

USE  tab7 ; 

PROCEDURE  dpinend(new_node , list_head:  IN  OUT  PtrTrkFile); 

END  dpmla; 
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--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  1  Oct  86 

--  MODULE  TYPE:  Detection  Processing  subroutine  vers  2.0 
--  PURPOSE:  Insert  a  node  at  the  end  of  a  linked  list 
--  NAME:  dp inend  ...  DPM1A.PKG 

--  This  subroutine  has  two  parameters:  new_node  is  a  pointer  to  the 
--  node  which  is  to  be  inserted,  list  head  is  a  pointer  to  the  list 
--  to  which  the  node  is  to  be  inserteH  at  the  end  of. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug ( on ) ; 

?  pragma  enumtab<on; ;  pragma  rangecheck(on)  ; 

WITH  tab 7 ; 

PACKAGE  30DY  dpmla  IS 
USE  tab7  ; 

PROCEDURE  dpinend(new_node , list_head:  IN  OUT  PtrTrkFile)  IS 
tp:  PtrTrkFile  :■=  NEW  TrkFile; 

BEGIN 

new  jiode . nxt_trk :-  null 

—  check  for  an  emotv  list 
IF  (listjiead  =  null]  THEM 
listens  ad  :•=  new  node; 

ELSE 

--  search  for  she  end  of  the  list 
to : —  lisL_head; 

WHILE  <tp.nxt_crK  =  null)  LOOP 
tp ' tp.nxt^frk; 

END  LOOP; 

--  insert  the  new  node  at  the  end  of  the  list 
tp.nxt_trk:=  new_node; 

END  IF; 

END  dpinend; 

END  dpmla; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Sep  86 

--  MODULE  TYPE:  process  vers  3.0 

--  PURPOSE:  Model  the  Radar  Scheduler  Function 

--  NAME:  Switch  Action  And  Display  Processing  ...  ARCM.LIB 

--  This  process  is  a  single  thread  module  which  models  the  Switch 
--  Action  And  Display  module  on  the  INTELLEC[tm]  MDS  system. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangechecfe(off) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  arcm  IS 

PROCEDURE  swcchactdply; 

END  arcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Oct  86 

--  MODULE  TYPE:  process  vers  3.0 

--  PURPOSE:  Model  the  Radar  Scheduler  Function 

--  NAME:  Switch  Action  And  Display  Processing  ...  ARCM.PKG 

--  This  process  is  a  single  thread  module  which  models  the  Switch 
—  Action  And  Display  module  on  the  INTELLEC[tm]  MDS  system. 

pragma  arithcheck(off ) ;  pragma  debug(off); 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  sacml , global , tab4 ; 

PACKAGE  BODY  arcm  IS 

USE  sadml , global ,tab4; 


PROCEDURE  swtchactdply  IS 
ctr , i :  INTEGER; 

3EGIN 


--  axecuta  operator  interface  module  ffrom  sadmi.pkg; 
oim(A_to_R. cb_doc t .mtrks , A_*o_R . op_doct  .mmtvis , 
A_to_R. 6p_docc. dply_rect ) ; 

—  initialise  Radar  Event  Priority  List 
ipl ;  —  from  global. pKg 

FOR  i  IN  1.. infinity  LOOP 

await (a _pid, ea_id, i) ; 

FOR  ctr  IN  1.  .126  LOOP 
null ; 

END  LOOP; 

END  LOOP; 

END  swtchactdply; 

END  arcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Sep  86 

--  MODULE  TYPE:  process  vers  2.0 

--  PURPOSE:  Model  the  Radar  Schedular  function 

--  NAME:  Track  Management  ..  TRCM.LIB 

--  The  purpose  of  this  module  is  to  manage  the  request  of  track  and 
--  missile  radar  events.  The  current  design  produces  static  data  for 
--  the  radar  scheduler  Test  Harness. 

pragma  arithcheckfof f ) ;  pragma  debug(off); 
pragma  enumtab(of f ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on) ;  pragma  rangecheck(on) ; 

PACKAGE  trcm  IS 

PROCEDURE  trackmgmt; 

END  trcm; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  3  Oct  86 

--  MODULE  TYPE:  process  vers  2.0 

--  PURPOSE:  Model  the  Radar  Schedular  function 

--  NAME:  Track  Management  ..  TRCM.PKG 

--  The  purpose  of  this  module  is  to  manage  the  request  of  track  and 
--  missile  radar  events.  The  current  design  produces  static  data  for 
--  the  radar  scheduler  Test  Harness. 

pragma  arithcheck(off ) ;  pragma  debug(off ) ; 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug ( on ) ; 

<t  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  global, tabO , tab2 , tab 7 , tmml , 3 trLib ; 

PACKAGE  BODY  trcm  IS 

USE  global , tabO , tab2 , tab? , tmml , S trLib ; 

PROCEDURE  trackmgmt  IS 

i , ppl :  INTEGER: 
node  ctr:  INTEGER: 
temo:  STRING (10); 
p:  TrkPtr:=  NEW  TrackNode; 
q:  PtrTrKFile :=  NEW  IrkFile; 

3EGIIJ 

tm_init : 

FOR  i  III  1.. infinity  LOOP 

--  wait  for  the  'raaar  Iood  event  value 
await( t_pia. et_ia, i) ; 

--  traverse  the  raaar  event  nriorttv  list 

ODl:=  1; 

ytfilLE  (ppl  /=  0)  LOOP 

IF  ( (pnn_lst(ppl) . que_id  =  track)  OR 

(pri_lst (ppl) .que_id  =  missile))  THEN 
--  traverse  the  event  queue  and  Track  File 

node_ctr:=  0; 

p :=  pri  lst(ppl) .que  otr.Tnode; 

3:=  ptrk;  --  ptrF  from  global. lib 

HILE  ((q  /=  null)  AND  (p  /=  null)  AND 

(node  ctr  <  pri_lst(ppl) .max_nodes) )  LOOP 
—  identify  this  event 

IF  (q.beam_data .mode  =  pri_lst(ppl) ,b_pri)  THEN 
node_ctr:=  node_ctr  +  1; 

--  set  track  node  mode 
p.info.mode:=  pri_lst(ppl) .b_pri; 

--  set  unique  beam  identifier 
temp :=  Int_to_Str (node_ctr ) ; 

IF  node_ctr  <10  THEN 

temp:=  Insert(M0" , temp, 1) ; 

END  IF; 

p. info .bid :=  Extract (pri_lst (ppl) . eventnm, 1 , 1) ; 
p. info. bid :=  Insert(temp,p.info.bid,2) ; 

p.info.p_trk:=  q; 

p. info .p_trk.be am_data .bid: =  p . info .bid; 
pri_lst(ppl) .status :=  true; 

--  reset  pointers 
p:=  p.nxt; 

END  IF; 
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ND 


q.-=  q.nxt_trk; 

END  LOOP; 

IF  (p  /=  null)  THEN 

p.info.p_trk:=  null; 

END  IF; 

END  IF; 

ppl : =  pri_lst(ppl) .nxt ; 

END  LOOP;  --  end  traverse  priority  list 
END  LOOP;  --  end  for  loop 
END  trackmgmt; 


154 


--  OWNER:  AEGIS  Modeling  Group 
--  DATE  OF  LAST  UPDATE:  3  Sep  86 

--  MODULE  TYPE:  Track  Management  Module  vers  2.0 

—  PURPOSE:  Initialize  track  events  in  the  Radar  Event  Priority  List 
--  NAME:  Track  Management  Initialize  ..  TMM1.LIB 

--  The  purpose  of  this  module  is  to  allocate  memory  for  track  nodes 

—  (table  2)  and  create  empty  request  queues  for  each  search  and 

--  special  request  event  in  the  Radar  Event  Priority  List  (table  0). 

pragma  arithcheck(of f )  ;  pragma  debug(off<); 
pragma  enumtab(off ) ;  pragma  rangecheck(off ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 

@  pragma  enumtab(on);  pragma  rangecheck(on) ; 

PACKAGE  tmml  IS 

PROCEDURE  tm_init; 

END  tmml ; 
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--  OWNER:  AEGIS  Modeling  Group 

--  DATE  OF  LAST  UPDATE:  30  Nov  86 

--  MODULE  TYPE:  Track  Management  Module  vers  2.0 

--  PURPOSE:  Initialize  track  events  in  the  Radar  Event  Priority  List 
--  NAME:  Track  Management  Initialize  ..  TMM1.PKG 

--  The  purpose  of  this  module  is  to  allocate  memory  for  track  nodes 
--  (table  2)  and  create  empty  request  queues  for  each  search  and 
--  special  request  event  in  the  Radar  Event  Priority  List  (table  0). 

pragma  arithcheck(of f ) ;  pragma  debug(off) ; 
pragma  enumtab(of f ) ;  pragma  rangecheck(of f ) ; 

@  pragma  arithcheck(on) ;  pragma  debug(on); 
d  pragma  enumtab(on);  pragma  rangecheck(on) ; 

WITH  tabO , tab2 , tab? ; 

PACKAGE  BODY  tmml  IS 

USE  tabO , tab2 , tab7 ; 

PROCEDURE  tm_init  IS 

qptr , p :  Trk?tr:=  MEW  TrackNoae; 

cf:  TrxPtr  ; 

ppl:  INTEGER :=  : 

:iode_ctr:  INTEGER; 

BEGIN 


--  traverse  the  Radar  Event  Priority  List 
WHILE  (ppl  /=  0)  LOOP 

IF  ( (pri_lst(ppl) . aue_id  -  track)  OR 

(,pri_Lstvppl)  ."que_id  -  missile))  THEN 

p.-=  pri_lst(ppl) .que_ptr.Tnode; 
node_ctr:=  0; 

WHILE  (node_ctr  <  pri_lst(ppl) .max_nodes)  LOOP 

node_ctr:=  node  ctr  +  1; 

q:=  NEW  TrackNoHe; 

q.info.p_trk:=  NEW  TrkFile; 

q. info .p_trk.beam_data :=  NEW  TrkData; 

q.nxt:=  null; 


--  insert  node  at  end  of  event  queue 
IF  (p  =  null)  THEN 
p-.=  q; 

bri_lst(ppl) .que_ptr.Tnode:=  q; 
ELSE 


tr :=  P; 

ILE  (qptr.nxt  /=  null) 
qptr:=  qptr.nxt; 

END  LOOP; 
cjptr.nxt:=  q; 


END 
END  LOOP; 

END  IF; 

ppl :=  pri_lst(ppl) .nxt; 


LOOP 


END  LOOP; 
END  tm_init; 
END  tmml ; 
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APPENDIX  E 

SAMPLE  RADAR  SCHEDULER  OUTPUT 


*  *  *  *  *  *  *  *  *  *  *  *  *  7*c  ^  *  a  *  *  *  *  ^  *  *  *  *  *  *  *  *  *  -k  -k  x  a  *  *  *  ;*:  7^  ^  7^  A  *  *  * 

********* *****  AEGIS  AN/SPY-1A  ************** 

**************  radar  scheduler  program  ************** 

Instructions  co  the  Operator: 

Input  the  number  of  tracks  to  be  initialised : 

NUMBER  OF  TRACKS  - >  50 

Input  the  number  of  scheduling  intervals  to  be  run: 

NUMBER  OF  INTERVALS  - >  100 

Define  interval  display  delay  period: 

SKIP  INTERVALS  - >  10 

3EGIN  EXECUTION 


Completed 

interval : 

10 

Comoleted 

interval : 

CO 

Completed 

interval : 

30 

Completed 

interval 

40 

Completed 

interval 

50 

Completed 

interval : 

50 

Completed 

interval : 

70 

Completed 

interval : 

80 

Completed 

interval : 

90 

Completed 

interval : 

100 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:  10 


A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 


G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID  G01  GO 2  G03  G04  G05 

OUEUE  POSIT  12343 


I -EVENT  -  HORIZON  SEARCH 

3EAM  ID  101  :02  203  104  105  106  107  108  109  110 

OUEUE  POSIT  123456739  10 


F- EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID  F01  F02  F03  F04  F05 

QUEUE  FOSIT  12345 


E-EVENT  -  OWN  SH-2  MISSILE  GUIDANCE 
3EAM  ID  E01  S02 

QUEUE  POSIT  1  2 


D- EVENT  -  ENGAGED  HOSTILE  TARGET 
3EAM  ID  001  002  D03  004  005 

OUEUE  POSIT  1  2  3  4  5 


H- EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
BEAM  ID  HOI  HO 2 

OUEUE  POSIT  1  2 


J- EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  PHIS  INTERVAL 


K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 


M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 


N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  N01  NO 2  N03  N04 

QUEUE  POSIT  1234 


O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  001  002  003  004  005 

QUEUE  POSIT  12345 


P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID  P01  P02 

QUEUE  POSIT  1  2 


Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID  Q01  Q02  Q03  Q04 

QUEUE  POSIT  1234 


V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  V01  V02  V03  V04  VOS  V06  V07  V08  V09  V10 

QUEUE  POSIT  123456789  10 
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R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  R01  R02  R03  R04  R05 

QUEUE  POSIT  12345 


S-EVENT  -  TRACK  TRANSITION 
BEAM  ID  SOI 

QUEUE  POSIT  1 


T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  TOl 

QUEUE  POSIT  1 


U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID  UOl  U02 

QUEUE  POSIT  1  2 


W- EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID  WOl  W02  WO 3  W04  W05  W06 

QUEUE  POSIT  123456 


K-EVENT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 


Y- EVENT  -  DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 


Z- EVENT  -  DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  FOR  SCHEDULER  INTERVAL:  LO 


3EAM  ID 

GOl 

GO  2 

GO  3 

G04 

GO  5 

101 

102 

103 

104 

105 

RESOURCES 

93 

36 

79 

72 

65 

62 

39 

36 

S3 

30 

DWELL  4 

1 

3 

4 

5 

8 

7 

3 

9 

10 

BEAM  ID 

106 

107 

108 

109 

no 

in 

FOl 

F02 

F03 

F04 

RESOURCES 

47 

44 

41 

38 

35 

32 

25 

18 

11 

4 

DWELL  # 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

BEAM  ID 

V01 

RESOURCES 

1 

DWELL  # 

21 
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REQUESTED  BEAMS  FOR  SCHEDULER 

INTERVAL : 

20 

A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS 

INTERVAL 

B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS 

INTERVAL 

C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS 

INTERVAL 

F-EVENT  -  PRE-ENGAGED  HOSTILE 
BEAM  ID  F01  F02  F03  F04 
QUEUE  POSIT  1234 

TARGET 

F05 

5 

E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 

BEAM  ID  E01  E02 

QUEUE  POSIT  1  2 

I -EVENT  -  HORIZON  SEARCH 

BEAM  ID  101  102  103  104 

QUEUE  POSIT  1234 

105  106  107 
5  6  7 

108 

8 

109 

9 

110 

10 

?- EVENT  -  UNEVALUATED  TRACK 

BEAM  ID  =01  =02 

QUEUE  POSIT  1  2 

O-EVENT  -  CONTROLLED  FRIENDLY 
BEAM  ID  001  002  Q03  004 
QUEUE  POSIT  1  ~  2  3  '  4 

TRACK 

R- EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  ROI  R02  R03  R04  R05 

QUEUE  POSIT  12345 


3-EVENT  -  TRACK  TRANSITION 
BEAM  ID  SOI 

QUEUE  POSIT  1 


T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  TOl 

QUEUE  POSIT  1 


U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID  UOl  U02 

QUEUE  POSIT  1  2 


D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID  D01  D02  D03  D04  D05 

QUEUE  POSIT  12345 


O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  OOl  002  003  004  005 

QUEUE  POSIT  12345 


N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  N01  N02  N03  N04 

QUEUE  POSIT  1234 


H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
BEAM  ID  HOI  H02 

QUEUE  POSIT  1  2 


G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID  G01  G02  G03  G04  G05 

QUEUE  POSIT  12345 
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V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  V01  V02  V03  V04  V05  V06  V07  V08  V09  VIO 

QUEUE  POSIT  123456789  10 


J-EVENT  - 

SPECIAL  5 CM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  - 

SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L- EVENT  - 

SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M- EVENT  - 

SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

W-EVENT  - 

SPECIAL  ABOVE  HORIZON  SEARCH 

BEAM  ID 

W01  WO 2  WO 3  WO 4  W05  W06 

QUEUE  ?OS 

IT  1  2  2  4  5  6 

X-EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y- EVENT  - 

DIAGNOSTIC  DWELL 

MO  REQUESTS  THIS  INTERVAL 

Z- EVENT  - 

DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULER  INTERVAL:  20 

BEAM  ID 

SOI  FQ2  SOB  F04  F05  SOI  E02  101 

:o2 

103 

RESOURCES 

33  36  79  72  35  38  51  43 

45 

42 

DWELL  4 

1234537  3 

9 

10 

BEAM  ID 

104  105  106  107  108  109  110  Ill 

?01 

P02 

RESOURCES 

39  36  33  30  27  24  21  18 

11 

4 

DWELL  # 

11  12  13  14  15  16  17  18 

19 

20 

BEAM  ID 

V01 

RESOURCES 

1 

DWELL  # 

21 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:  30 


A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 


F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID  F01  F02  F03  F04  F05 

QUEUE  POSIT  12345 


E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID  EQ1  E02 

QUEUE  POSIT  1  2 


D- EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID  D01  002  D03  D04  D05 

QUEUE  POSIT  12345 


H- EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
SEAM  ID  HOI  HO 2 

QUEUE  POSIT  1  2 


U-SVENT  -  CONFIRMED  FRIENDLY  TRACK 
SEAM  ID  U01  U02 

QUEUE  POSIT  L  2 


I- EVENT  -  HORIZON  SEARCH 

SEAM  ID  IG1  .102  102  104  105  106  107  108  109  110 

QUEUE  POSIT  122-55739  10 


S- EVENT  -  TRACK  TRANSITION 
BEAM  ID  501 

QUEUE  POSIT  1 


T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  T01 

QUEUE  POSIT  1 


R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  R01  R02  R03  R04  R05 

QUEUE  POSIT  12345 


G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID  G01  G02  G03  G04  G05 

QUEUE  POSIT  12345 


Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID  Q01  Q02  Q03  Q04 

QUEUE  POSIT  1234 


P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID  P01  P02 

QUEUE  POSIT  1  2 


O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  001  002  003  004  005 

QUEUE  POSIT  12345 


V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE  POSIT  123456789  10 
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N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  N01  NO 2  N03  N04 

QUEUE  POSIT  1234 


J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 


M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 


W-EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID  WOl  WO 2  W03  W04  W05  W06 

QUEUE  POSIT  123456 


X-EVENT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 


Y-EVENT  -  DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 


Z- EVENT  -  DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  FOR  SCHEDULER  INTERVAL:  30 


BEAM  ID  F01  F 02  F03  F04  F05  E01  E02  D01  D02  D03 

RESOURCES  93  36  79  72  65  53  51  44  37  30 

DWELL  9  123456739  10 


BEAM  ID  D04  D05  HOI  H02 
RESOURCES  23  16  9  2 
DWELL  #  11  12  13  14 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:  40 


A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 


E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID  E01  E02 

QUEUE  POSIT  1  2 


I -EVENT  -  HORIZON  SEARCH 

BEAM  ID  101  102  103  104  105  106  107  108  109  110 

QUEUE  POSIT  12345673  9  10 


D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID  D01  D02  D03  D04  D05 

QUEUE  POSIT  12345 


H-SVENT  -  HIGH  ?RI  TRACK  CONFIRMATION 
BEAM  ID  HOI  HO 2 

QUEUE  POSIT  1  2 


G-SVENT  -  HIGH  ?RI  TRACK  TRANSITION 
BEAM  ID  GOl  GO 2  G03  G04  G05 

QUEUE  POSIT  12345 


U- EVENT  -  CONFIRMED  FRIENDLY  TRACK 
SEAM  ID  U01  U02 

QUEUE  POSIT  1  2 


F- EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID  F01  F02  F03  F04  F05 

QUEUE  POSIT  12345 


S -EVENT  -  TRACK  TRANSITION 
BEAM  ID  SOI 

QUEUE  POSIT  1 


T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  T01 

QUEUE  POSIT  1 


R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  R01  R02  R03  R04  R05 

QUEUE  POSIT  12345 


Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID  Q01  Q02  Q03  Q04 

QUEUE  POSIT  1234 


P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID  P01  P02 

QUEUE  POSIT  1  2 


O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  001  002  003  004  005 

QUEUE  POSIT  12345 


V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE  POSIT  123456789  10 
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N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  N01  N02  N03  N04 

QUEUE  POSIT  1234 


J-EVENT  - 

SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  - 

SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L- EVENT  - 

SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M- EVENT  - 

SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

W -EVENT  - 

SPECIAL  ABOVE  HORIZON  SEARCH 

BEAM  ID 

W01  WO 2  WO 3  WO 4  W05  W06 

QUEUE  ?OS 

IT  1  2  3  4  5  6 

X-EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y-EVENT  - 

DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Z- EVENT  - 

DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULER  INTERVAL 

40 

BEAM  ID 

eoi  E02  ioi  :o2  :o3  :o4  : 

05 

106 

10  7 

108 

RESOURCES 

93  36  33  30  77  74 

71 

66 

65 

82 

DWELL  -4 

1  2  3  4  5  6 

7 

3 

9 

10 

BEAM  ID 

109  110  Ill  D01  D02  DOS  D04 

DOS 

HOI 

HO  2 

RESOURCES 

59  56  53  46  39  32 

25 

18 

11 

4 

DWELL  # 

11  12  13  14  15  16 

17 

18 

19 

20 

BEAM  ID 

V01 

RESOURCES 

1 

DWELL  # 

21 

165 


REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:  50 


A-EVENT 

-  ECM  BURNTHROUGH 

NO  REQUESTS  THIS 

INTERVAL 

B- EVENT 

-  TARGET  DEFINITION 

NO  REQUESTS  THIS 

INTERVAL 

C- EVENT 

-  SPECIAL  TEST 

NO  REQUESTS  THIS 

INTERVAL 

D-EVENT  -  ENGAGED  HOSTILE  TARGET 

BEAM  ID  D01  DO 2  D03  D04  DOS 

QUEUE  POSIT  12345 

H- EVENT  -  HIGH  ?RI  TRACK  CONFIRMATION 
SEAM  ID  HOI  HO 2 

QUEUE  POSIT  1  2 


I -EVENT  -  HORIZON  SEARCH 

BEAM  ID  101  102  103  104  105  106  107  103  IC9  110 

QUEUE  POSIT  123455739  10 


0- EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  001  002  003  004  005 

QUEUE  POSIT  1  2345 


Q-SVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID  G01  GO 2  G03  G04  G05 

QUEUE  POSIT  12345 


P- EVENT  -  UNEVALUATED  TRACK 
BEAM  ID  POI  P02 

QUEUE  POSIT  1  2 


F- EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID  F01  F02  F03  FC4  F05 

QUEUE  POSIT  12345 


Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID  Q01  Q02  Q03  Q04 

QUEUE  POSIT  1234 


N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  N01  N02  N03  N04 

QUEUE  POSIT  1234 


E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID  E01  E02 

QUEUE  POSIT  1  2 


U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID  U01  U02 

QUEUE  POSIT  1  2 


S-EVENT  -  TRACK  TRANSITION 
BEAM  ID  SOI 

QUEUE  POSIT  1 


T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  T01 

QUEUE  POSIT  1 


V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE  POSIT  123456789  10 
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R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  R01  R02  R03  R04  R05 

QUEUE  POSIT  12345 


J-EVENT  - 

SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  - 

SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS 

INTERVAL 

L-EVENT  - 

SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS 

INTERVAL 

M- EVENT  - 

SPECIAL  TARGET  ACOUISITION 

NO  REQUESTS  THIS 

INTERVAL 

W- EVENT  - 

SPECIAL  ABOVE  HORIZON  SEARCH 

BEAM  ID 

W01  WO 2  WO 3  W04 

W05  W06 

QUEUE  POSIT  1234 

5  6 

X- EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS 

INTERVAL 

T- EVENT  - 

DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS 

INTERVAL 

Z-EVENT  - 

DUMMY  DWELL 

NO  REQUESTS  THIS 

INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULER  INTERVAL 

50 

BEAM  ID 

D01  D02  DOS  D04 

DO 5  HOI  HO 2 

101 

102 

103 

RESOURCES 

93  36  79  72 

65  S3 

51 

43 

45 

19 

DWELL  3 

13  3  4 

5  6 

7 

3 

a 

10 

3EAM  ID 

104  105  106  107 

108  109  110 

Ill 

001 

002 

RESOURCES 

39  36  33  30 

27  24 

21 

18 

11 

4 

DWELL  # 

11  12  13  14 

15  16 

17 

18 

19 

20 

BEAM  ID 

V01 

RESOURCES 

1 

DWELL  # 

21 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:  60 


A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 


H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
BEAM  ID  HOI  HO 2 

QUEUE  POSIT  1  2 


G- EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID  G01  GO 2  G03  G04  G05 

QUEUE  POSIT  12345 


I -EVENT  -  HORIZON  SEARCH 

BEAM  ID  101  102  103  104  105  106  107  108  109  110 

QUEUE  POSIT  123456789  10 


O-EVENT  -  CONTROLLED  FRIENDLY  TRACK 

Beam  id  001  002  003  004 

QUEUE  POSIT  i  ~  2  ~  3  ~  4 


R- EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  ROl  R02  ROB  R04  R05 

QUEUE  POSIT  12345 


S- EVENT  -  TRACK  TRANSITION 
BEAM  ID  SOI 

QUEUE  POSIT  1 


T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  T01 

QUEUE  POSIT  1 


F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID  F01  F02  F03  F04  F05 

QUEUE  POSIT  12345 


E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID  E01  E02 

QUEUE  POSIT  1  2 


D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID  D01  D02  D03  D04  D05 

QUEUE  POSIT  12345 


P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID  P01  P02 

QUEUE  POSIT  1  2 


O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  001  002  003  004  005 

QUEUE  POSIT  12345 


N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  N01  N02  N03  N04 

QUEUE  POSIT  1234 


V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE  POSIT  123456789  10 
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U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID  U01  U02 

QUEUE  POSIT  1  2 


J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 


M-SVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 


W- EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID  W01  WO 2  W03  W04  WOS  WO 6 

QUEUE  POSIT  123456 


K-EVENT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 


Y-EVENT  -  DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 


Z- EVENT  -  DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  FOR  SCHEDULER  INTERVAL:  60 


BEAM  ID  HOI  HO 2  SOI  SO 2  SOB  G04  SOS  101  102  I 03 

RESOURCES  93  36  79  72  55  5£  31  43  45  42 

DWELL  4  123456  '39  10 


BEAM  ID  104  105  106  107  103  IC9  110  Ill  Q01  Q02 

RESOURCES  39  36  33  30  27  24  21  18  11  4 

DWELL  #  11  12  13  14  15  16  17  18  19  20 


BEAM  ID  V01 
RESOURCES  1 
DWELL  #  21 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL: 


70 


A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 


D-EVENT  -  ENGAGED  HOSTILE  TARGET 
3EAM  ID  D01  D02  D03  D04  D05 

QUEUE  POSIT  12345 


H- EVENT  -  HIGH  ?RI  TRACK  CONFIRMATION 
BEAM  ID  HOI  HO 2 

QUEUE  POSIT  1  2 


G- EVENT  -  HIGH  ?RI  TRACK  TRANSITION 
3EAM  ID  G01  GO 2  G03  G04  G05 

QUEUE  POSIT  12345 


F- EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID  F01  P02  r03  P04  r'05 

QUEUE  POSIT  12  2^5 


E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID  E01  E02 

QUEUE  POSIT  1  2 


I -EVENT  -  HORIZON  SEARCH 

BEAM  ID  101  102  103  104  105  106  107  108  109  110 

QUEUE  POSIT  122455739  10 


S- EVENT  -  TRACK  TRANSITION 
BEAM  ID  SOI 

QUEUE  POSIT  1 


U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID  U01  U02 

QUEUE  POSIT  1  2 


T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  T01 

QUEUE  POSIT  1 


R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  R01  R02  R03  R04  R05 

QUEUE  POSIT  12345 


Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID  Q01  Q02  Q03  Q04 

QUEUE  POSIT  1234 


P -EVENT  -  UNEVALUATED  TRACK 
BEAM  ID  P01  P02 

QUEUE  POSIT  1  2 


O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  001  002  003  004  005 

QUEUE  POSIT  12345 


N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  N01  N02  N03  N04 

QUEUE  POSIT  1234 
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V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  V01  V02  V03  V04  V05  V06  V07  V08  V09  VIO 

QUEUE  POSIT  123456789  10 


J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 


M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 


W-EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID  W01  W02  W03  W04  WO 5  W06 

QUEUE  POSIT  123456 


X-EVENT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 


7-EVENT  -  DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 


Z- EVENT  -  DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  FOR  SCHEDULER  INTERVAL:  70 


BEAM  ID 
RESOURCES 
DWELL  # 

D01 

93 

DOE 

O 

CO 

2 

DOS 

79 

3 

D04 

72 

a 

D05 

65 

5 

HOI  HO 2  G01 
53  31  44 

6  7  8 

G02 

37 

9 

G03 

30 

10 

BEAM  ID 

G04 

GO  5 

F01 

F02 

RESOURCES 

23 

16 

9 

2 

DWELL  # 

11 

12 

13 

14 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:  80 


A-EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 


G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID  G01  GO 2  G03  G04  G05 

QUEUE  POSIT  12345 


.--EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
3EAM  ID  F01  F02  F03  F04  F05 

QUEUE  POSIT  12345 


E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID  E01  E02 

QUEUE  POSIT  1  2 


D-EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID  D01  D02  D03  D04  D05 

QUEUE  POSIT  12345 


N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  M01  NO 2  NO 3  M04 

QUEUE  POSIT  1234 


I -EVENT  -  HORIZON  SEARCH 

BEAM  ID  101  102  103  104  105  106  107  208  109  110 

QUEUE  POSIT  1  23456739  10 


O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  001  002  003  004  005 

QUEUE  POSIT  12345 


H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
BEAM  ID  HOI  H02 

QUEUE  POSIT  1  2 


U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID  U01  U02 

QUEUE  POSIT  1  2 


P-EVENT  -  UNEVALUATED  TRACK 
BEAM  ID  P01  P02 

QUEUE  POSIT  1  2 


S-EVENT  -  TRACK  TRANSITION 
BEAM  ID  SOI 

QUEUE  POSIT  1 


T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  T01 

QUEUE  POSIT  1 


V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE  POSIT  123456789  10 


R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  R01  R02  R03  R04  R05 

QUEUE  POSIT  12345 
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Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID  001  002  Q03  004 

QUEUE  POSIT  1234 


J-EVENT  - 

SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K-EVENT  - 

SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  - 

SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M- EVENT  - 

SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

W- EVENT  - 
3EAM  ID 

queue  ?os: 

SPECIAL  ABOVE  HORIZON  SEARCH 

W01  WO 2  WO 3  W04  W05  W06 

IT  1  2  3  4  5  6 

X- EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y- EVENT  - 

DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 

2- EVENT  - 

DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULER  INTERVAL: 

30 

3EAM  ID 
RESOURCES 
DWELL  4 

G01  G02  GO 3  G04  G05  F01  F02 

93  36  "9  72  65  53  51 

1  2  3  4  5  5  7 

F03  F04 
44  37 

3  9 

?05 

30 

10 

BEAM  ID 
RESOURCES 
DWELL  # 

E01  £02  D01  D02 

23  16  9  2 

11  12  13  14 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL: 


A- EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 


F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID  F01  F02  F03  F04  F05 

QUEUE  POSIT  12345 


E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
3EAM  ID  SOI  E02 

QUEUE  POSIT  l  2 


D- EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID  D01  D02  D03  D04  DOS 

QUEUE  POSIT  12345 


H- EVENT  -  HIGH  ?RI  TRACK  CONFIRMATION 
BEAM  ID  HOI  HO 2 

QUEUE  POSIT  i  2 


?- EVENT  -  UNEVALUATED  TRACK 
BEAM  ID  ?01  ?Q2 

QUEUE  POSIT  1  2 


I -EVENT  -  HORIZON  SEARCH 

BEAM  ID  101  102  103  104  105  106  107  103  109  110 

QUEUE  POSIT  123455739  10 


G-BVENT  -  HIGH  PRI  TRACK  TRANSITION 
3EAM  ID  G01  GO 2  G03  G04  G05 

QUEUE  POSIT  12345 


O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  001  002  003  004  005 

QUEUE  POSIT  12345 


N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  N01  N02  N03  N04 

QUEUE  POSIT  1234 


Q-EVENT  -  CONTROLLED  FRIENDLY  TRACK 
BEAM  ID  Q01  Q02  Q03  Q04 

QUEUE  POSIT  1234 


U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID  U01  U02 

QUEUE  POSIT  1  2 


R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  R01  R02  R03  R04  R05 

QUEUE  POSIT  12345 


S-EVENT  -  TRACK  TRANSITION 
BEAM  ID  SOI 

QUEUE  POSIT  1 


V-EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  V01  V02  V03  V04  V05  V06  V07  V08  V09  V10 

QUEUE  POSIT  123456789  10 
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T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  T01 

QUEUE  POSIT  1 


J-EVENT  - 

SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 

K- EVENT  - 

SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 

L-EVENT  - 

SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 

M- EVENT  - 

SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THIS  INTERVAL 

W-EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 

BEAM  ID  W01  W02  W03  W04  NOS  W06 

QUEUE  POSIT  123456 

X- EVENT  - 

SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 

Y- EVENT  - 

DIAGNOSTIC  DWELL 

MO  REQUESTS  THIS  INTERVAL 

2-EVENT  - 

DUMMY  DWELL 

NO  REQUESTS  THIS  INTERVAL 

SCHEDULED 

DWELLS  FOR  SCHEDULER  INTERVAL: 

90 

BEAM  ID 
RESOURCES 
DWELL  4 

FOl  P02  F03  F04  FOS  EOl  E02 

93  36  79  72  55  53  51 

1  2  3  4  5  5  7 

D01  D02 
44  37 

3  9 

003 

30 

10 

BEAM  ID 
RESOURCES 
DWELL  # 

D04  DO 5  HOI  H02 

23  16  9  2 

11  12  13  14 
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REQUESTED  BEAMS  FOR  SCHEDULER  INTERVAL:  100 


A- EVENT  -  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


B-EVENT  -  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


C-EVENT  -  SPECIAL  TEST 

NO  REQUESTS  THIS  INTERVAL 


H-EVENT  -  HIGH  PRI  TRACK  CONFIRMATION 
BEAM  ID  HOI  HO 2 

QUEUE  POSIT  1  2 


I -EVENT  -  HORIZON  SEARCH 

BEAM  ID  101  102  103  104  105  106  107  108  109  110 

QUEUE  POSIT  123456739  10 


E-EVENT  -  OWN  SM-2  MISSILE  GUIDANCE 
BEAM  ID  E01  E02 

QUEUE  POSIT  1  2 


Q- EVENT  -  CONTROLLED  FRIENDLY  TRACK 
3EAM  ID  Q01  002  003  Q04 

QUEUE  POSIT  1  '  2  3  4 


S-EVENT  -  TRACK  TRANSITION 
3EAM  ID  SOI 

QUEUE  POSIT  1 


R-EVENT  -  TRACK  CONFIRMATION 
BEAM  ID  R01  R02  R03  R04  R05 

QUEUE  POSIT  12345 


D- EVENT  -  ENGAGED  HOSTILE  TARGET 
BEAM  ID  D01  D02  D03  D04  D05 

QUEUE  POSIT  12345 


G-EVENT  -  HIGH  PRI  TRACK  TRANSITION 
BEAM  ID  G01  G02  G03  G04  G05 

QUEUE  POSIT  12345 


P -EVENT  -  UNEVALUATED  TRACK 
BEAM  ID  P01  P02 

QUEUE  POSIT  1  2 


F-EVENT  -  PRE-ENGAGED  HOSTILE  TARGET 
BEAM  ID  F01  F02  F03  F04  F05 

QUEUE  POSIT  12345 


O-EVENT  -  ASSUMED  HOSTILE  TRACK 
BEAM  ID  001  002  003  004  005 

QUEUE  POSIT  12345 


N-EVENT  -  CONFIRMED  HOSTILE  TRACK 
BEAM  ID  N01  NO 2  N03  N04 

QUEUE  POSIT  1234 


U-EVENT  -  CONFIRMED  FRIENDLY  TRACK 
BEAM  ID  U01  U02 

QUEUE  POSIT  1  2 


T-EVENT  -  ASSUMED  FRIENDLY  TRACK 
BEAM  ID  T01 

QUEUE  POSIT  1 
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V- EVENT  -  ABOVE  HORIZON  SEARCH 

BEAM  ID  VOl  V02  V03  V04  V05  V06  V07  V08  V09  VIO 

QUEUE  POSIT  123456789  10 


J-EVENT  -  SPECIAL  ECM  BURNTHROUGH 

NO  REQUESTS  THIS  INTERVAL 


K-EVENT  -  SPECIAL  TARGET  DEFINITION 

NO  REQUESTS  THIS  INTERVAL 


L-EVENT  -  SPECIAL  MANUAL  SCAN 

NO  REQUESTS  THIS  INTERVAL 


M-EVENT  -  SPECIAL  TARGET  ACQUISITION 

NO  REQUESTS  THiS  INTERVAL 


W- EVENT  -  SPECIAL  ABOVE  HORIZON  SEARCH 
BEAM  ID  W01  WO 2  W03  W04  W05  W06 

QUEUE  POSIT  123456 


X-EVENT  -  SIMULATION  DWELL 

NO  REQUESTS  THIS  INTERVAL 


Y- EVENT  -  DIAGNOSTIC  DWELL 

NO  REQUESTS  THIS  INTERVAL 


Z -EVENT  -  DUMMY  DWELL 

MO  REQUESTS  THIS  INTERVAL 


SCHEDULED  DWELLS  FOR  SCHEDULER  INTERVAL:  100 


BEAM  ID 

HOI 

H02 

101  102  103 

:o4 

105 

106 

:o7  :os 

RESOURCES 

92 

36 

32  30  77 

71 

63 

65  52 

DWELL  = 

- 

o 

3  4  5 

3 

7? 

9  10 

BEAM  ID 

109 

110 

Ill  E01  E02 

QOl 

Q02 

Q03 

Q04  SOI 

RESOURCES 

59 

56 

53  46  39 

32 

25 

18 

11  4 

DWELL  # 

11 

12 

13  14  15 

16 

17 

18 

19  20 

BEAM  ID 

VOl 

RESOURCES 

1 

DWELL  # 

21 
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